IDE代码编辑器开发工具前端桌面应用插件系统后端AI 应用【免费下载链接】theiaEclipse Theia is a cloud desktop IDE framework implemented in TypeScript.项目地址https://gitcode.com/gh_mirrors/th/theia点击查看免费下载本指南以仓库根目录的 CONTRIBUTING.md 为骨架系统讲解 Eclipse Theia一个基于 TypeScript 实现的云与桌面 IDE 框架的开源协作方式如何提问、报告 Bug、提交功能请求如何通过 Eclipse Contributor AgreementECA与 DCO 签名保证贡献合法性并结合仓库内的 编码规范、PR 评审规则 以及 .github 下的模板与 CI 工作流给出从提 Issue 到 PR 合入全流程的可操作指引。读完本文你将掌握向 Theia 提交高质量、可被合入的代码贡献所需的全部流程与规范细节。理解 Theia 的模块化架构与贡献动机Theia 是一个年轻的开源项目采用模块化架构。其核心目标之一是确保任何 Theia 应用都能通过**扩展extension**被定制和增强。因此虽然主仓库main repository包含 IDE 类应用的一些通用功能如文件系统、导航器视图但大部分功能并不强制要求放进核心仓库而是可以独立开发成扩展。这一点直接决定了贡献的边界能在核心之外实现的功能应当优先考虑以扩展形式交付这一点在 PR 关闭规则 中也被明确列为关闭 PR 的理由之一。仓库的物理结构也印证了这一点参见 doc/Developing.md 与 doc/code-organization.mdpackages运行时包包含core包及其扩展dev-packages开发期包如theia/cli、theia/ext-scriptsexamples示例应用包括浏览器版与 Electron 版doc项目工作机制文档scriptsnpm 脚本使用的 JavaScript 工具。如何参与贡献1. 提问Asking Questions在 Theia GitHub 仓库中直接开一个 issue 提问完全没问题。维护者会在问题得到解答后关闭该 issue并打上question标签。提交前请先检索确认该问题是否已被问过包括仓库内与 Stack Overflow 等渠道避免重复提问。2. 报告 BugReporting Bugs发现 Bug 时的标准动作先查重检查该 Bug 是否已经被提交甚至是否已被修复补充已有 issue如果找到仍未解决的 issue请追加你的复现案例提供一切有助于复现与定位的信息新建 issue如果确实没有已有报告再新建一个。仓库为此提供了标准的 bug_report.md 模板要求填写Bug DescriptionBug 的详细描述Steps to Reproduce清晰、编号化的复现步骤Additional Information操作系统、Theia 版本以及日志、截图、录屏等补充材料。模板还特别注明安全漏洞不要通过公开 issue 报告而应遵循根目录 SECURITY.md 中的流程通过 Eclipse Foundation 的漏洞报告渠道进行协调披露coordinated disclosure。3. 报告功能请求Reporting Feature Requests对于新功能或新想法可以直接提交请求。仓库同样提供了 feature_request.md 模板。如果类似的功能请求已经存在请以评论或其他形式反馈你的兴趣同时提供**具体的用例场景use case**将非常有助于维护者理解该请求背后的动机。此外.github/ISSUE_TEMPLATE/config.yml 关闭了空白 issueblank_issues_enabled: false并将问题类咨询导向 GitHub Discussions。4. Pull Requests开工前先沟通这是贡献代码的核心路径。关键原则是在你投入大量时间编写将要被合入并长期维护的代码之前先通过一个 issue 与团队沟通挑选一个你愿意认领的 issue在 issue 中明确告知团队你愿意处理它并说明你的实现思路团队会乐于给予指导和反馈避免方向性返工。PR 的评审与合入遵循 doc/pull-requests.md 中的规则下文会展开详述。Eclipse Contributor AgreementECA在贡献被项目团队接受之前贡献者必须电子签署 Eclipse Contributor AgreementECA。其核心规定包括非 committer 提交的 commit必须在提交说明commit message的末尾footer包含Signed-off-by字段表明作者知悉该贡献所依据的条款非 committer 还须拥有一个Eclipse Foundation 账户并在档案中留存一份已签署的 ECA。关于提交者行为的更多细节可参考 Eclipse Committer Handbook 中关于提交commit的章节。ECA 的电子签署在 Eclipse 官方网站完成这是进入合入门槛的第一步也是下文 DCO 签名能够生效的法律前提。签名Sign your workDeveloper Certificate of OriginTheia 采用 Linux 内核社区流传下来的Developer Certificate of OriginDCO机制来证明补丁来源合法。签名sign-off就是在补丁说明末尾追加一行简单的声明。DCO 全文与含义DCO 1.1 全文如下Developer Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129 Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developers Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.简言之签名者证明该补丁要么是自己原创的要么基于合适的开源许可之下的既有工作要么是直接由其他已认证者提供且未作修改同时贡献是公开的相关个人信息与签名会被永久记录并可能随本项目或相关开源许可被再分发。如何签名在每个 git commit message 末尾添加一行Signed-off-by: Joe Smith joe.smithemail.com注意必须使用真实姓名不接受化名或匿名贡献。如果已经配置好 git 的user.name和user.email可以通过git commit -s自动签名git config user.name Your Real Name git config user.email youexample.com git commit -s签名是 PR 评审清单中的强制检查项评审者在 Review Checklist 中会核对Commits are signed-off参见checklist-sign-off规则其链接正是本文所在的 CONTRIBUTING.md 的 Sign your work 一节。编码规范合入门槛的硬性要求CONTRIBUTING.md 将 doc/coding-guidelines.md 指定为必须遵循的编码规范评审清单中的checklist-project-org也要求新代码与项目组织和编码约定保持一致。以下是核心规范的精要完整版请直接阅读原文档。缩进、导入与命名缩进每级缩进使用 4 个空格导入使用organize imports整理导入顺序并确保导入路径可用例如.ts文件应从/src/而非/lib/导入否则可能破坏构建命名规则type、enum值使用 PascalCase函数/方法、属性/局部变量使用 camelCase命名尽量使用完整单词terminalWidgetId优于termWdgId文件名使用小写、短横线分隔如document-provider.ts并以导出的主类型命名文件避免单个文件包含多个大类每个类一个文件类型与文件命名要唯一且具体QuickInputTitleButton优于TitleButton避免搜索时出现重复记录私有属性不要使用_前缀例外通过 get/set 暴露属性且内部字段用下划线、或将内部数据附加到用户可见的 JSON 对象上事件名遵循on[Will|Did]VerbNoun?模式标识事件即将发生onWill还是已发生onDidkeybinding context 与 key 命名必须全局唯一避免运行时冲突例如terminalHideSearch优于hideSearch。类型、接口与依赖注入DI类型不要导出仅内部使用的类型或函数不向全局命名空间引入新类型/值方法必须显式声明返回类型以免方法体改动引发意外破坏性变更接口不要使用I前缀同名实现用Impl后缀如TaskDefinitionRegistryImpl可替换的服务对于大多数公共服务应声明接口 Symbol 默认实现让采用者既能子类化默认实现也能提供完全独立的实现仅对真正内部、不作为扩展点的服务才直接以类作为注入令牌coding-guidelines.md 中给出了TaskDefinitionRegistry与bindRootContributionProvider的完整示例注入方式优先属性注入property injection而非构造注入新增构造注入依赖属于破坏性变更对象初始化用postConstruct()修饰的方法而非构造函数单例必须显式inSingletonScope()函数与工厂不要导出可被覆盖的函数应转为类方法如把createWebSocket收进WebSocketProvider类以便子类化可定制对象的创建优先使用注入的工厂factory而非new XYZImpl()不要使用 InversifyJS 的multiInject改用 Theia 的ContributionProvider工具。国际化Internationalization/Localization用户可见的文本命令/菜单标签、消息/通知/对话框、quick-input 占位符、偏好项等必须用nls.localize(key, defaultValue, ...args)本地化参数作为args传入以填充{0}、{1}等占位符// bad nls.localize(hello, Hello there ${name}.); // good nls.localize(hello, Hello there {0}., name);如果默认值在 VS Code 语言包中已存在可用nls.localizeByDefault(Close)自动查找翻译键否则使用新键格式为theia/package/id。命令标签优先使用Command.toLocalizedCommand/Command.toDefaultLocalizedCommand工具函数。富内容HTML本地化应使用 Markdown 渲染MarkdownRenderer而非拼接 HTML 字符串确需 HTML 时必须先用DOMPurify.sanitize()消毒。此外preload 阶段的模块不得在模块顶层读取本地化字符串此时Preloader尚未运行相关违规可由theia/preload-localization-checkESLint 规则检出。样式、CSS 与主题优先箭头函数仅必要时才给参数加括号循环与条件体必须加大括号左大括号与被修饰语句同行括号内不加多余空白一个变量语句只声明一个变量else紧随右大括号CSS 类名使用lower-case-with-dashes全局类加theia前缀不要在代码里定义样式应引入 CSS 类以便在 devtools 中调试主题不要引入 CSS 颜色变量应实现ColorContribution并用ColorRegistry.register注册颜色不要硬编码颜色值通过--theia-前缀引用 VS Code 颜色如var(--theia-widget-shadow)widget.shadow中的点替换为短横线新颜色必须从现有 VS Code 颜色派生直接引用或Color.lighten(...)变换变量命名遵循object.property模式secondaryButton.disabledForeground而非button.secondary.disabled.foregroundReact编译使用自动 JSX runtime无需仅为写 JSX 而导入 React事件处理器中禁止绑定函数this.onClickDiv.bind(this)或每次渲染新建箭头函数应使用类属性箭头函数protected onClickDiv () {...}以避免破坏 React 元素缓存导致重复渲染。URI / Path 与资源处理前后端之间传递URI 而非路径URI 在 JSON-RPC 服务中以字符串传递如RemoteFileSystemServerURI 是 OS 无关的规范化表示可避免前后端操作系统差异导致的不兼容前端从 URI 取路径用FileService.fsPath后端用FileUri.fsPath绝不用于前端前端路径操作使用 Theia 的PathAPI 而非 Node.jspath模块后端则直接用 Node.jsfs/fs-extraURI 必须显式指定 scheme不要用字符串拼接操作 URI/Path应使用URI/Path的join、resolve、relative能力能正确处理尾部分隔符等边界情况展示用LabelProvider.getLongName(uri)/getName(uri)/getIcon(uri)获取系统级可读表示打包资源如 Electronasar归档内的脚本在交给外部进程shell、调试适配器等前必须先经BundledResourceProvider.resolveExternalPath(...)解析且应解析脚本所在目录而非单个文件保证相互引用的文件保持在一起。日志、Workspace Trust 与 To Do 标签日志Inversify 上下文中应注入具名 loggerinject(ILogger) named(my-logger)命名遵循[optional-purpose]package-name:class-name#optional-suffix约定如remote:BackendRemoteServiceImpl这样可针对用途、包、具体类单独配置日志级别Workspace Trust执行工作区代码任务、调试配置、脚本或加载工作区内容提示模板、影响行为的配置文件的功能必须先经WorkspaceTrustService检查或请求信任被限制的功能应注册WorkspaceRestrictionContribution以在状态栏提示菜单/命令可见性可用isWorkspaceTrustedcontext key 控制To Do 标签代码中统一使用两个标准标签——stubbedVS Code API 的占位实现会被 API 状态页标记与monaco-uplift提示在升级 Monaco 编辑器后应补充或修复的功能可附带所需最低版本。PR 评审规则从打开到合入doc/pull-requests.md 详细规定了 PR 的评审与合入规则与 CONTRIBUTING.md 的先沟通再开工原则衔接。要点如下。打开 PROpening a Pull Request每个 PR 描述必须遵循 .github/PULL_REQUEST_TEMPLATE.md模板包含What it does / How to test / Follow-ups / Breaking changes / Attribution / Review checklist等区块人类在环human-in-the-loop贡献者可以使用任何工具包括 LLM编写代码但提交给他人评审前必须亲自阅读并审查所有 LLM 生成的代码或文本贡献者始终是作者对其贡献负全责评审期间应能独立回答关于自己工作的问题可以提前打开设计评审 PR标注 draft 或 WIP 前缀但需显式评论说明这是设计评审请求PR 打开后的修改应保持为独立 commitfixup待评审结束后再 squash 以保持干净历史changelog只有破坏性变更breaking changes必须在 PR 描述中声明并在 CHANGELOG.md 中登记非破坏性变更不手动添加条目release 时会统一收集以避免频繁的合并冲突。请求评审与评审清单满足以下条件才可请求评审PR 模板已填、作者已充分测试、作者已按评审清单自查。评审清单Review Checklist核心项包括新代码按How to test区块构建并通过测试新代码符合 项目组织 与 编码约定破坏性变更已论证并在 changelog 中登记非破坏性变更缺失条目不构成评审问题新依赖合理且经过验证——仓库通过license:check见下文检查新依赖复制/移植的代码经 CQContribution Questionnaire审批3pp/dash 许可证检查应为绿色新文件带正确的版权头当前年份 贡献实体名称commit 已签名对应本文的 DCO 章节每个 commit 有有意义的标题与说明正文commit 历史已 rebase 到 master只含有意义且精简的提交可用git pull -r或git fetch git rebase用户可见文本已用nls服务国际化。评审、批准与合入Reviewing / Approving / Landing评审者应核对 PR 描述、按How to test构建验证、确保评审清单全部通过不要求单个评审者全查可以只验证其中一部分并给出评论反馈实质改变应用或组件行为的大变更应征求多个贡献组织的代表评审确保与项目目标一致、与下游采用者产品兼容Request Changes 的边界评审者不能因个人偏好要求变更此类请求应被驳回不能要求处理 PR 范围之外的议题应驳回并另开 issue代码风格偏好不应在 PR 上争论而应在 dev meeting 讨论、写入编码规范后再统一执行Approval每次批准都应附带支持性评论无评论的批准应被驳回dismissed批准意味着评审者准备好合入该 PR多个评审者共同评审时不满意的评审者应以request changes阻止合入合入条件CI 构建成功、作者已接受 ECA、评审清单全部通过且至少一位评审者批准、无未解决的评审评论满足条件的 PR 应及时合入避免 release 前积压——合入责任依次落在作者若是 committer、作者所在组织的 committer、批准评审者回滚RevertingPR 合入后造成回归的作者与维护者有 2 天时间解决否则必须回滚关闭Closing评审者不能无故关闭 PR可关闭的情形包括功能应作为外部 Theia/VS Code 扩展实现、涉及核心扩展间的结构性或 API 变更须由资深维护者处理、应是第三方组件Theia 不是日志框架或代理服务器、改变开发基础设施如测试框架、打包、违反 human-in-the-loop 策略。从 Issue 到合入仓库里的配套设施将 CONTRIBUTING.md 的流程落到实操还需要了解仓库中这些配套文件与命令均可在本地仓库中直接查看验证。Issue / PR 模板与讨论模板bug_report.mdBug 报告模板上文已述feature_request.md功能请求模板config.yml关闭空白 issue问题导向 DiscussionsPULL_REQUEST_TEMPLATE.mdPR 模板Review checklist区块直接引用本 CONTRIBUTING.md 与 doc/pull-requests.md.github/DISCUSSION_TEMPLATE包含 general、ideas、improvements、q-a 等讨论模板。CI/CD 与许可证检查ci-cd.yml对 push 到 master 与 PR 运行npm ci、npm run build含check_git_status.sh验证构建产物无污染、npm run lint、npm run download:plugins、npm run test:theia、test:browser与test:electronLinux 下经xvfb-run并在 Windows / Ubuntu / macOS 三个 OS 上以 Node 24.x 与 26.x 双版本矩阵运行license-check.yml3PP License Check 工作流在package-lock.json变化时运行npm run license:check。对应根 package.json 中的脚本npm run license:check使用configs/license-check-config.json基于 Eclipse Dash Licenses 工具批量检查依赖许可评审模式为npm run license:check:review因仓库暂未定义 PAT secret需贡献者或评审者在本地运行。构建、测试与本地开发贡献者在提交前通常需要在本机构建验证相关命令集中在根 package.json 中npm install # 安装并链接所有 workspace 包postinstall 会执行 theia-patch、compute-references npm run compile # 编译全部 TypeScript 包 npm run lint # ESLint 检查 npm run build:browser # 构建浏览器示例应用 npm run build:electron # 构建 Electron 示例应用 npm run test:theia # 运行所有 theia/* 包的单测 npm run download:plugins # 下载示例应用所需插件 npm run start:browser # 启动浏览器版示例http://localhost:3000更完整的构建、调试、profile 与 Windows 构建指引见 doc/Developing.md单元测试与 API 集成测试分别见 doc/Testing.md 与 doc/api-testing.md。结语贡献前的自检清单综合 CONTRIBUTING.md 与仓库配套文档一次合格贡献的完整路径可以浓缩为在 issue 中认领工作并沟通思路设计先行签署 ECA配置 git 真实姓名/邮箱编码严格遵循 doc/coding-guidelines.md命名、DI、国际化、主题、URI、日志、Workspace Trust 等使用 PULL_REQUEST_TEMPLATE.md 填写 PR 描述提供可复现的How to test每个 commit 包含Signed-off-by签名git commit -s保持有意义的提交历史本地通过 lint / 单测 / 构建并自查 评审清单提交 PR 后接受评审意见用独立 fixup commit 迭代合入前 squash。只要沿这条路径走你的贡献就能顺利通过 CI 与评审成为 Eclipse Theia 生态的一部分。赞分享IDE代码编辑器开发工具前端桌面应用插件系统后端AI 应用【免费下载链接】theiaEclipse Theia is a cloud desktop IDE framework implemented in TypeScript.项目地址https://gitcode.com/gh_mirrors/th/theia点击查看免费下载相关推荐Dapr 贡献指南从 Issue 到合入的完整协作流程与 DCO 签名规范Dapr 贡献指南从 Issue 到合入的完整协作流程与 DCO 签名规范 Dapr 是一个跨云边、以事件驱动架构结合工作流编排的分布式应用可移植运行时仓库后端微服务云原生消息队列AI AgentEclipse Theia 的 Pull Request 协作规范从提交、评审到合入的完整流程指南Eclipse Theia 的 Pull Request 协作规范从提交、评审到合入的完整流程指南 Eclipse Theia 仓库根目录 https://IDE代码编辑器开发工具前端桌面应用插件系统后端AI 应用kotlinx.coroutines 贡献指南从 Issue 提交到 PR 合入的完整工作流kotlinx.coroutines 贡献指南从 Issue 提交到 PR 合入的完整工作流 本篇指南面向希望在 kotlinx.coroutines 仓库中异步编程并发编程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 IDE代码编辑器开发工具前端桌面应用插件系统后端AI 应用【免费下载链接】theiaEclipse Theia is a cloud desktop IDE framework implemented in TypeScript.项目地址https://gitcode.com/gh_mirrors/th/theia点击查看免费下载本指南以仓库根目录的 CONTRIBUTING.md 为骨架系统讲解 Eclipse Theia一个基于 TypeScript 实现的云与桌面 IDE 框架的开源协作方式如何提问、报告 Bug、提交功能请求如何通过 Eclipse Contributor AgreementECA与 DCO 签名保证贡献合法性并结合仓库内的 编码规范、PR 评审规则 以及 .github 下的模板与 CI 工作流给出从提 Issue 到 PR 合入全流程的可操作指引。读完本文你将掌握向 Theia 提交高质量、可被合入的代码贡献所需的全部流程与规范细节。理解 Theia 的模块化架构与贡献动机Theia 是一个年轻的开源项目采用模块化架构。其核心目标之一是确保任何 Theia 应用都能通过**扩展extension**被定制和增强。因此虽然主仓库main repository包含 IDE 类应用的一些通用功能如文件系统、导航器视图但大部分功能并不强制要求放进核心仓库而是可以独立开发成扩展。这一点直接决定了贡献的边界能在核心之外实现的功能应当优先考虑以扩展形式交付这一点在 PR 关闭规则 中也被明确列为关闭 PR 的理由之一。仓库的物理结构也印证了这一点参见 doc/Developing.md 与 doc/code-organization.mdpackages运行时包包含core包及其扩展dev-packages开发期包如theia/cli、theia/ext-scriptsexamples示例应用包括浏览器版与 Electron 版doc项目工作机制文档scriptsnpm 脚本使用的 JavaScript 工具。如何参与贡献1. 提问Asking Questions在 Theia GitHub 仓库中直接开一个 issue 提问完全没问题。维护者会在问题得到解答后关闭该 issue并打上question标签。提交前请先检索确认该问题是否已被问过包括仓库内与 Stack Overflow 等渠道避免重复提问。2. 报告 BugReporting Bugs发现 Bug 时的标准动作先查重检查该 Bug 是否已经被提交甚至是否已被修复补充已有 issue如果找到仍未解决的 issue请追加你的复现案例提供一切有助于复现与定位的信息新建 issue如果确实没有已有报告再新建一个。仓库为此提供了标准的 bug_report.md 模板要求填写Bug DescriptionBug 的详细描述Steps to Reproduce清晰、编号化的复现步骤Additional Information操作系统、Theia 版本以及日志、截图、录屏等补充材料。模板还特别注明安全漏洞不要通过公开 issue 报告而应遵循根目录 SECURITY.md 中的流程通过 Eclipse Foundation 的漏洞报告渠道进行协调披露coordinated disclosure。3. 报告功能请求Reporting Feature Requests对于新功能或新想法可以直接提交请求。仓库同样提供了 feature_request.md 模板。如果类似的功能请求已经存在请以评论或其他形式反馈你的兴趣同时提供**具体的用例场景use case**将非常有助于维护者理解该请求背后的动机。此外.github/ISSUE_TEMPLATE/config.yml 关闭了空白 issueblank_issues_enabled: false并将问题类咨询导向 GitHub Discussions。4. Pull Requests开工前先沟通这是贡献代码的核心路径。关键原则是在你投入大量时间编写将要被合入并长期维护的代码之前先通过一个 issue 与团队沟通挑选一个你愿意认领的 issue在 issue 中明确告知团队你愿意处理它并说明你的实现思路团队会乐于给予指导和反馈避免方向性返工。PR 的评审与合入遵循 doc/pull-requests.md 中的规则下文会展开详述。Eclipse Contributor AgreementECA在贡献被项目团队接受之前贡献者必须电子签署 Eclipse Contributor AgreementECA。其核心规定包括非 committer 提交的 commit必须在提交说明commit message的末尾footer包含Signed-off-by字段表明作者知悉该贡献所依据的条款非 committer 还须拥有一个Eclipse Foundation 账户并在档案中留存一份已签署的 ECA。关于提交者行为的更多细节可参考 Eclipse Committer Handbook 中关于提交commit的章节。ECA 的电子签署在 Eclipse 官方网站完成这是进入合入门槛的第一步也是下文 DCO 签名能够生效的法律前提。签名Sign your workDeveloper Certificate of OriginTheia 采用 Linux 内核社区流传下来的Developer Certificate of OriginDCO机制来证明补丁来源合法。签名sign-off就是在补丁说明末尾追加一行简单的声明。DCO 全文与含义DCO 1.1 全文如下Developer Certificate of Origin Version 1.1 Copyright (C) 2004, 2006 The Linux Foundation and its contributors. 1 Letterman Drive Suite D4700 San Francisco, CA, 94129 Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed. Developers Certificate of Origin 1.1 By making a contribution to this project, I certify that: (a) The contribution was created in whole or in part by me and I have the right to submit it under the open source license indicated in the file; or (b) The contribution is based upon previous work that, to the best of my knowledge, is covered under an appropriate open source license and I have the right under that license to submit that work with modifications, whether created in whole or in part by me, under the same open source license (unless I am permitted to submit under a different license), as indicated in the file; or (c) The contribution was provided directly to me by some other person who certified (a), (b) or (c) and I have not modified it. (d) I understand and agree that this project and the contribution are public and that a record of the contribution (including all personal information I submit with it, including my sign-off) is maintained indefinitely and may be redistributed consistent with this project or the open source license(s) involved.简言之签名者证明该补丁要么是自己原创的要么基于合适的开源许可之下的既有工作要么是直接由其他已认证者提供且未作修改同时贡献是公开的相关个人信息与签名会被永久记录并可能随本项目或相关开源许可被再分发。如何签名在每个 git commit message 末尾添加一行Signed-off-by: Joe Smith joe.smithemail.com注意必须使用真实姓名不接受化名或匿名贡献。如果已经配置好 git 的user.name和user.email可以通过git commit -s自动签名git config user.name Your Real Name git config user.email youexample.com git commit -s签名是 PR 评审清单中的强制检查项评审者在 Review Checklist 中会核对Commits are signed-off参见checklist-sign-off规则其链接正是本文所在的 CONTRIBUTING.md 的 Sign your work 一节。编码规范合入门槛的硬性要求CONTRIBUTING.md 将 doc/coding-guidelines.md 指定为必须遵循的编码规范评审清单中的checklist-project-org也要求新代码与项目组织和编码约定保持一致。以下是核心规范的精要完整版请直接阅读原文档。缩进、导入与命名缩进每级缩进使用 4 个空格导入使用organize imports整理导入顺序并确保导入路径可用例如.ts文件应从/src/而非/lib/导入否则可能破坏构建命名规则type、enum值使用 PascalCase函数/方法、属性/局部变量使用 camelCase命名尽量使用完整单词terminalWidgetId优于termWdgId文件名使用小写、短横线分隔如document-provider.ts并以导出的主类型命名文件避免单个文件包含多个大类每个类一个文件类型与文件命名要唯一且具体QuickInputTitleButton优于TitleButton避免搜索时出现重复记录私有属性不要使用_前缀例外通过 get/set 暴露属性且内部字段用下划线、或将内部数据附加到用户可见的 JSON 对象上事件名遵循on[Will|Did]VerbNoun?模式标识事件即将发生onWill还是已发生onDidkeybinding context 与 key 命名必须全局唯一避免运行时冲突例如terminalHideSearch优于hideSearch。类型、接口与依赖注入DI类型不要导出仅内部使用的类型或函数不向全局命名空间引入新类型/值方法必须显式声明返回类型以免方法体改动引发意外破坏性变更接口不要使用I前缀同名实现用Impl后缀如TaskDefinitionRegistryImpl可替换的服务对于大多数公共服务应声明接口 Symbol 默认实现让采用者既能子类化默认实现也能提供完全独立的实现仅对真正内部、不作为扩展点的服务才直接以类作为注入令牌coding-guidelines.md 中给出了TaskDefinitionRegistry与bindRootContributionProvider的完整示例注入方式优先属性注入property injection而非构造注入新增构造注入依赖属于破坏性变更对象初始化用postConstruct()修饰的方法而非构造函数单例必须显式inSingletonScope()函数与工厂不要导出可被覆盖的函数应转为类方法如把createWebSocket收进WebSocketProvider类以便子类化可定制对象的创建优先使用注入的工厂factory而非new XYZImpl()不要使用 InversifyJS 的multiInject改用 Theia 的ContributionProvider工具。国际化Internationalization/Localization用户可见的文本命令/菜单标签、消息/通知/对话框、quick-input 占位符、偏好项等必须用nls.localize(key, defaultValue, ...args)本地化参数作为args传入以填充{0}、{1}等占位符// bad nls.localize(hello, Hello there ${name}.); // good nls.localize(hello, Hello there {0}., name);如果默认值在 VS Code 语言包中已存在可用nls.localizeByDefault(Close)自动查找翻译键否则使用新键格式为theia/package/id。命令标签优先使用Command.toLocalizedCommand/Command.toDefaultLocalizedCommand工具函数。富内容HTML本地化应使用 Markdown 渲染MarkdownRenderer而非拼接 HTML 字符串确需 HTML 时必须先用DOMPurify.sanitize()消毒。此外preload 阶段的模块不得在模块顶层读取本地化字符串此时Preloader尚未运行相关违规可由theia/preload-localization-checkESLint 规则检出。样式、CSS 与主题优先箭头函数仅必要时才给参数加括号循环与条件体必须加大括号左大括号与被修饰语句同行括号内不加多余空白一个变量语句只声明一个变量else紧随右大括号CSS 类名使用lower-case-with-dashes全局类加theia前缀不要在代码里定义样式应引入 CSS 类以便在 devtools 中调试主题不要引入 CSS 颜色变量应实现ColorContribution并用ColorRegistry.register注册颜色不要硬编码颜色值通过--theia-前缀引用 VS Code 颜色如var(--theia-widget-shadow)widget.shadow中的点替换为短横线新颜色必须从现有 VS Code 颜色派生直接引用或Color.lighten(...)变换变量命名遵循object.property模式secondaryButton.disabledForeground而非button.secondary.disabled.foregroundReact编译使用自动 JSX runtime无需仅为写 JSX 而导入 React事件处理器中禁止绑定函数this.onClickDiv.bind(this)或每次渲染新建箭头函数应使用类属性箭头函数protected onClickDiv () {...}以避免破坏 React 元素缓存导致重复渲染。URI / Path 与资源处理前后端之间传递URI 而非路径URI 在 JSON-RPC 服务中以字符串传递如RemoteFileSystemServerURI 是 OS 无关的规范化表示可避免前后端操作系统差异导致的不兼容前端从 URI 取路径用FileService.fsPath后端用FileUri.fsPath绝不用于前端前端路径操作使用 Theia 的PathAPI 而非 Node.jspath模块后端则直接用 Node.jsfs/fs-extraURI 必须显式指定 scheme不要用字符串拼接操作 URI/Path应使用URI/Path的join、resolve、relative能力能正确处理尾部分隔符等边界情况展示用LabelProvider.getLongName(uri)/getName(uri)/getIcon(uri)获取系统级可读表示打包资源如 Electronasar归档内的脚本在交给外部进程shell、调试适配器等前必须先经BundledResourceProvider.resolveExternalPath(...)解析且应解析脚本所在目录而非单个文件保证相互引用的文件保持在一起。日志、Workspace Trust 与 To Do 标签日志Inversify 上下文中应注入具名 loggerinject(ILogger) named(my-logger)命名遵循[optional-purpose]package-name:class-name#optional-suffix约定如remote:BackendRemoteServiceImpl这样可针对用途、包、具体类单独配置日志级别Workspace Trust执行工作区代码任务、调试配置、脚本或加载工作区内容提示模板、影响行为的配置文件的功能必须先经WorkspaceTrustService检查或请求信任被限制的功能应注册WorkspaceRestrictionContribution以在状态栏提示菜单/命令可见性可用isWorkspaceTrustedcontext key 控制To Do 标签代码中统一使用两个标准标签——stubbedVS Code API 的占位实现会被 API 状态页标记与monaco-uplift提示在升级 Monaco 编辑器后应补充或修复的功能可附带所需最低版本。PR 评审规则从打开到合入doc/pull-requests.md 详细规定了 PR 的评审与合入规则与 CONTRIBUTING.md 的先沟通再开工原则衔接。要点如下。打开 PROpening a Pull Request每个 PR 描述必须遵循 .github/PULL_REQUEST_TEMPLATE.md模板包含What it does / How to test / Follow-ups / Breaking changes / Attribution / Review checklist等区块人类在环human-in-the-loop贡献者可以使用任何工具包括 LLM编写代码但提交给他人评审前必须亲自阅读并审查所有 LLM 生成的代码或文本贡献者始终是作者对其贡献负全责评审期间应能独立回答关于自己工作的问题可以提前打开设计评审 PR标注 draft 或 WIP 前缀但需显式评论说明这是设计评审请求PR 打开后的修改应保持为独立 commitfixup待评审结束后再 squash 以保持干净历史changelog只有破坏性变更breaking changes必须在 PR 描述中声明并在 CHANGELOG.md 中登记非破坏性变更不手动添加条目release 时会统一收集以避免频繁的合并冲突。请求评审与评审清单满足以下条件才可请求评审PR 模板已填、作者已充分测试、作者已按评审清单自查。评审清单Review Checklist核心项包括新代码按How to test区块构建并通过测试新代码符合 项目组织 与 编码约定破坏性变更已论证并在 changelog 中登记非破坏性变更缺失条目不构成评审问题新依赖合理且经过验证——仓库通过license:check见下文检查新依赖复制/移植的代码经 CQContribution Questionnaire审批3pp/dash 许可证检查应为绿色新文件带正确的版权头当前年份 贡献实体名称commit 已签名对应本文的 DCO 章节每个 commit 有有意义的标题与说明正文commit 历史已 rebase 到 master只含有意义且精简的提交可用git pull -r或git fetch git rebase用户可见文本已用nls服务国际化。评审、批准与合入Reviewing / Approving / Landing评审者应核对 PR 描述、按How to test构建验证、确保评审清单全部通过不要求单个评审者全查可以只验证其中一部分并给出评论反馈实质改变应用或组件行为的大变更应征求多个贡献组织的代表评审确保与项目目标一致、与下游采用者产品兼容Request Changes 的边界评审者不能因个人偏好要求变更此类请求应被驳回不能要求处理 PR 范围之外的议题应驳回并另开 issue代码风格偏好不应在 PR 上争论而应在 dev meeting 讨论、写入编码规范后再统一执行Approval每次批准都应附带支持性评论无评论的批准应被驳回dismissed批准意味着评审者准备好合入该 PR多个评审者共同评审时不满意的评审者应以request changes阻止合入合入条件CI 构建成功、作者已接受 ECA、评审清单全部通过且至少一位评审者批准、无未解决的评审评论满足条件的 PR 应及时合入避免 release 前积压——合入责任依次落在作者若是 committer、作者所在组织的 committer、批准评审者回滚RevertingPR 合入后造成回归的作者与维护者有 2 天时间解决否则必须回滚关闭Closing评审者不能无故关闭 PR可关闭的情形包括功能应作为外部 Theia/VS Code 扩展实现、涉及核心扩展间的结构性或 API 变更须由资深维护者处理、应是第三方组件Theia 不是日志框架或代理服务器、改变开发基础设施如测试框架、打包、违反 human-in-the-loop 策略。从 Issue 到合入仓库里的配套设施将 CONTRIBUTING.md 的流程落到实操还需要了解仓库中这些配套文件与命令均可在本地仓库中直接查看验证。Issue / PR 模板与讨论模板bug_report.mdBug 报告模板上文已述feature_request.md功能请求模板config.yml关闭空白 issue问题导向 DiscussionsPULL_REQUEST_TEMPLATE.mdPR 模板Review checklist区块直接引用本 CONTRIBUTING.md 与 doc/pull-requests.md.github/DISCUSSION_TEMPLATE包含 general、ideas、improvements、q-a 等讨论模板。CI/CD 与许可证检查ci-cd.yml对 push 到 master 与 PR 运行npm ci、npm run build含check_git_status.sh验证构建产物无污染、npm run lint、npm run download:plugins、npm run test:theia、test:browser与test:electronLinux 下经xvfb-run并在 Windows / Ubuntu / macOS 三个 OS 上以 Node 24.x 与 26.x 双版本矩阵运行license-check.yml3PP License Check 工作流在package-lock.json变化时运行npm run license:check。对应根 package.json 中的脚本npm run license:check使用configs/license-check-config.json基于 Eclipse Dash Licenses 工具批量检查依赖许可评审模式为npm run license:check:review因仓库暂未定义 PAT secret需贡献者或评审者在本地运行。构建、测试与本地开发贡献者在提交前通常需要在本机构建验证相关命令集中在根 package.json 中npm install # 安装并链接所有 workspace 包postinstall 会执行 theia-patch、compute-references npm run compile # 编译全部 TypeScript 包 npm run lint # ESLint 检查 npm run build:browser # 构建浏览器示例应用 npm run build:electron # 构建 Electron 示例应用 npm run test:theia # 运行所有 theia/* 包的单测 npm run download:plugins # 下载示例应用所需插件 npm run start:browser # 启动浏览器版示例http://localhost:3000更完整的构建、调试、profile 与 Windows 构建指引见 doc/Developing.md单元测试与 API 集成测试分别见 doc/Testing.md 与 doc/api-testing.md。结语贡献前的自检清单综合 CONTRIBUTING.md 与仓库配套文档一次合格贡献的完整路径可以浓缩为在 issue 中认领工作并沟通思路设计先行签署 ECA配置 git 真实姓名/邮箱编码严格遵循 doc/coding-guidelines.md命名、DI、国际化、主题、URI、日志、Workspace Trust 等使用 PULL_REQUEST_TEMPLATE.md 填写 PR 描述提供可复现的How to test每个 commit 包含Signed-off-by签名git commit -s保持有意义的提交历史本地通过 lint / 单测 / 构建并自查 评审清单提交 PR 后接受评审意见用独立 fixup commit 迭代合入前 squash。只要沿这条路径走你的贡献就能顺利通过 CI 与评审成为 Eclipse Theia 生态的一部分。赞分享IDE代码编辑器开发工具前端桌面应用插件系统后端AI 应用【免费下载链接】theiaEclipse Theia is a cloud desktop IDE framework implemented in TypeScript.项目地址https://gitcode.com/gh_mirrors/th/theia点击查看免费下载相关推荐Dapr 贡献指南从 Issue 到合入的完整协作流程与 DCO 签名规范Dapr 贡献指南从 Issue 到合入的完整协作流程与 DCO 签名规范 Dapr 是一个跨云边、以事件驱动架构结合工作流编排的分布式应用可移植运行时仓库后端微服务云原生消息队列AI AgentEclipse Theia 的 Pull Request 协作规范从提交、评审到合入的完整流程指南Eclipse Theia 的 Pull Request 协作规范从提交、评审到合入的完整流程指南 Eclipse Theia 仓库根目录 https://IDE代码编辑器开发工具前端桌面应用插件系统后端AI 应用kotlinx.coroutines 贡献指南从 Issue 提交到 PR 合入的完整工作流kotlinx.coroutines 贡献指南从 Issue 提交到 PR 合入的完整工作流 本篇指南面向希望在 kotlinx.coroutines 仓库中异步编程并发编程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考