Monaco Editor 维护指南稳定版发布流程、webpack 插件发布与 TypeScript 更新的完整实操MAINTAINING.md 深度解读【免费下载链接】monaco-editorA browser based code editor项目地址: https://gitcode.com/gh_mirrors/mo/monaco-editor本文基于 monaco-editor 仓库的维护者文档 MAINTAINING.md完整拆解该项目的三类核心维护任务触发 rc-build 并发布稳定版monaco-editor、发布新的monaco-editor-webpack-plugin、以及更新内置的 TypeScript 编译器。读完本文你将理解package.json中version、vscodeRef、monaco-editor-core三个字段的含义与联动关系掌握从 VS Code 上游 commit 到 npm 发布的完整链路并能通过仓库源码如 build/importTypescript.ts验证每一步操作的底层实现。上图来自 CONTRIBUTING.md它解释了维护工作的前提Monaco Editor Core 直接由 VS Code 源码构建本仓库monaco-editor在其之上叠加基础语言特性。因此每一次发布本质上是锁定一个 VS Code commit → 发布对应的 core → 发布本仓库的封装层。一、日常职责issue 标签治理MAINTAINING.md 开篇仅限维护者阅读要求维护者确保每个未指派的 issue 都被正确打标并给出了一条按标签过滤的 Inbox Queue 查询视图排除feature-request、upstream、info-needed、bug已分类的 issue。这是发布工作的前置动作正确打标能区分上游 VS Code 问题upstream标签需要反馈到 VS Code 仓库与本仓库可修复问题未分类的 issue 堆积会污染对比验证下文 Compare 步骤时的回归判断依据。二、发布稳定版 monaco-editor 构建这是 MAINTAINING.md 中 Publishing a stable build monaco-editor build 一节的核心内容。整个流程分为四个阶段触发 rc 构建 → 对比验证 → 更新仓库元数据 → 触发正式发布构建。2.1 阶段一触发 rc-build打开 VS Code 仓库的最新稳定 release 分支文档以release/1.89分支为示例实际使用时必须替换为最新 VS Code 版本号找到该分支的最新 commit id并复制打开 Azure DevOps 的 Monaco 构建定义文档中为definitionId421的 Run pipeline填入两个关键参数The VS Code commit id.上一步复制的 commit idThe prerelease version.填写rc等待流水线跑完得到一个基于该 VS Code commit 的 rc候选构建。从仓库结构看这一步的产物正是根 package.json 中devDependencies.monaco-editor-core所指向的上游包——当前仓库锁定的是monaco-editor-core: 0.56.0-dev-20260625package.json即由某个 VS Code 开发版本构建出的 dev/core 包。2.2 阶段二对比上一稳定版与 nightly/rc 构建文档要求打开 monaco-editor 官方 playground 的双编辑器对比模式Compare Last Stable With Nightly人工核验左侧是上一个稳定版last stable右侧是刚构建的 rc 构建核对构建元数据同时记录本次 rc/nightly 构建的三个关键字段它们直接决定下一阶段要写入package.json的值lastNightly.currentVersion本次 rc 构建的版本号lastNightly.vscodeCommitId本次构建所用的 VS Code commit idnextStableVersion由对比结果推导的下一个稳定版本号以及本次相对上一稳定版的API diffAPI 变更 / 破坏性变更 / 新特性列表用于撰写 CHANGELOG。这一步的价值在于monaco-editor 是 VS Code 编辑器核心的浏览器封装回归必须通过与上一稳定版并排编辑真实代码来确认而不是只看构建日志。2.3 阶段三更新 package.json、锁文件与 CHANGELOG确认无回归后在仓库中执行三处更新更新 package.json对应文档 Update package.json 条目{ name: monaco-editor, // ① 设为对比阶段得到的 nextStableVersion version: 0.56.0, // ② 设为对比阶段得到的 vscodeCommitIdVS Code 的完整 commit hash vscodeRef: f487add297079a02eb836810185b165e50cadabc, devDependencies: { // ③ 设为对比阶段得到的 lastNightly.currentVersion monaco-editor-core: 0.56.0-dev-20260625, typescript: ^5.9.3 } }当前仓库的 package.json 就是刚完成一次稳定发布后的真实状态version为0.56.0vscodeRef指向一个具体的 VS Code commit。CONTRIBUTING.md 也明确说明For a stable release, the commit specified invscodeRefin package.json specifies the commit of VS Code that is used to buildmonaco-editor-core——即vscodeRef是稳定版可复现构建的锚点保证任何人按该 commit 重建 core 都能得到与 npm 上一致的编辑器内核。执行npm install刷新 lockfile使 package-lock.json 与新的monaco-editor-core版本一致更新 CHANGELOG.md按文档要求包含三类内容API Changes / Breaking Changes / New and noteworthy直接使用对比阶段产出的 diff致谢thank you mentions文档建议使用 VS Code 官方的 acknowledgement 工具生成且只勾选 monaco-editor 的贡献条目。仓库内 CHANGELOG.md 的实际结构印证了这一规范例如0.56.0条目分为 Breaking Changes / New Features and APIs / Fixes 三段CHANGELOG.md更早的0.50.0条目末尾还带有 Contributions to monaco-editor 致谢列表CHANGELOG.md。提交代码并创建 PR等待合并。2.4 阶段四触发正式构建并勾选发布项PR 合并后打开 Azure DevOps 的正式构建定义文档中为definitionId416的 Trigger build同时勾选两个复选框✅ Publish Monaco Editor Core✅ Publish Monaco Editor前者发布与vscodeRef对应的monaco-editor-corenpm 包后者发布本仓库的monaco-editornpm 包。两者版本号必须与 2.3 节写入package.json的值保持一致用户侧的安装命令才是npm install monaco-editor0.56.02.5 版本字段语义速查字段位置发布时的取值来源作用versionpackage.json对比阶段的nextStableVersionmonaco-editornpm 包版本号vscodeRefpackage.json对比阶段的vscodeCommitId锚定 core 构建所用的 VS Code commit保证稳定版可复现devDependencies.monaco-editor-corepackage.json对比阶段的lastNightly.currentVersion构建期依赖的 core 包版本如0.56.0-dev-20260625三、发布新的 webpack 插件monaco-editor-webpack-pluginMAINTAINING.md 的 Publish new webpack plugin 一节描述了 webpack-plugin/ 子包的发布流程。该插件独立于主包维护当前版本为7.1.1webpack-plugin/package.json其peerDependencies声明了与主包的兼容区间monaco-editor: 0.31.0webpack-plugin/package.json。3.1 发布步骤在webpack-plugin目录下安装本地插件依赖npm install .执行npm run import-editor——该脚本会把当前monaco-editor的导出结构同步进插件代码如 webpack-plugin/src/plugins/AddWorkerEntryPointPlugin.ts、webpack-plugin/src/loaders/include.ts 等文件中的语言/特性清单根据脚本是否产生代码变更走两条不同的分支分支 A脚本未产生任何变更说明插件与新版编辑器二进制兼容更新package.json中的 peer dependency使用||形式保留旧版本兼容例如monaco-editor: 0.27.x || 0.28.x更新 webpack-plugin/README.md 的Version Matrix表格把新版编辑器追加到插件当前主版本那一行的右侧单元格如7.*.* | 0.31.0见 webpack-plugin/README.md使用npm version minor升次版本号使用npm publish发布。分支 B脚本产生了代码变更说明插件必须随编辑器大版本演进更新package.json中的 peer dependency 为单一区间例如monaco-editor: 0.29.x在 webpack-plugin/README.md 的 Version Matrix 中新增一行记录插件新主版本 ↔ 编辑器新主版本的映射使用npm version major升主版本号使用npm publish发布。最后务必把 tag push 回上游remember to push tags upstream——npm version生成的 git tag 是版本矩阵可追溯的关键。这个有无变更 → minor/major的分支规则本质上是把语义化版本与是否需要消费者配合升级绑定无变更意味着兼容扩展有变更意味着破坏性升级。四、更新内置 TypeScriptMAINTAINING.md 的 Updating TypeScript 一节只有四步但每步都有明确的落点修改根 package.json 中typescript的版本号当前为^5.9.3执行npm install .让新版本进入node_modules执行npm run import-typescript对应 package.json 中的import-typescript: ts-node ./build/importTypescriptadopt new APIs——即适配 TypeScript 编译器新版 API 带来的破坏性变更。4.1 import-typescript 脚本到底做了什么build/importTypescript.ts 的源码完整解释了第 3 步的行为这也是维护者只需改一个版本号的原因源与目标脚本从node_modules/typescript/lib读取产物写入src/language/typescript/libbuild/importTypescript.ts。也就是说monaco-editor 并不是在运行时require(typescript)而是把编译器内联进仓库源码随编辑器一起打进浏览器 bundlelib 文件内联importLibs()遍历所有lib.*.d.ts文件把内容转义后写入lib.tslibFileMap与lib.index.tslibFileSet供编辑器内联补全、// ts-ignore提示等功能使用build/importTypescript.ts版本元数据脚本执行npm ls typescript --depth0 --json取回实际安装版本写入src/language/typescript/lib/typescriptServicesMetadata.ts导出typescriptVersion常量build/importTypescript.ts编辑器 UI 可据此显示内嵌编译器版本CJS → ESM 改造读入typescript.js后脚本在文件头部注入var require undefined; var module { exports: {} };的桩定义并在尾部追加export var createLanguageService ts.createLanguageService;等显式导出build/importTypescript.ts。注释说明这样做是因为产物仅以 ESM 形态被消费桩定义让 bundler 能正确 tree-shake同时 TS 运行时也能自行判断不在 Node 下生成的每个文件顶部都会带上Do not edit directly! This file is generated using \npm run import-typescript 的标记build/importTypescript.ts防止维护者手改生成物。因此第 4 步adopt new APIs的工作量是确定的只需检查消费typescriptServices.js的编辑器侧代码如 src/languages/features/typescript/ 下的语言服务适配层是否仍与新导出的 API 匹配。五、发布前后的本地验证虽然 MAINTAINING.md 聚焦发布流程但发布质量依赖仓库自带的构建与测试命令维护者在触发流水线前可在本地先行验证均已在根 package.json 中定义CONTRIBUTING.md 的 Running the editor tests 一节给出了完整序列npm install npm run build-monaco-editor # 构建 monaco-editor先构建 LSP client再打 core 包 npm run test # 校验 samples 运行所有语言语法测试 npm run package-for-smoketest # 用 webpack / esbuild / vite 三种打包器各打一份包 npm run smoketest-debug # Playwright 驱动的浏览器级冒烟测试其中语法测试由test:grammars驱动node --import tsx --test src/languages/definitions/*/*.test.tspackage.json冒烟测试配置在 test/smoke/playwright.config.ts。这些命令覆盖了编辑器核心 语言包 三种主流打包器的组合与 2.2 节 playground 双编辑器对比互为补充前者是自动化回归后者是发布前的人工终审。六、关键路径索引主题仓库路径维护者操作手册本文主体MAINTAINING.md版本号 / vscodeRef / core 依赖package.json、package.json变更日志发布内容模板CHANGELOG.mdcore 与 VS Code 的关系、测试序列CONTRIBUTING.mdTypeScript 内联脚本build/importTypescript.ts冒烟测试配置test/smoke/playwright.config.tswebpack 插件包webpack-plugin/package.json、webpack-plugin/README.md要点回顾monaco-editor 的一次稳定发布 锁定 VS Code commitvscodeRef→ 以rc预发布参数构建并做双编辑器人工对比 → 同步package.json三个版本字段与 CHANGELOG → 合并 PR 后在正式流水线勾选 Publish Monaco Editor Core 与 Publish Monaco Editor 完成双包发布webpack 插件与 TypeScript 更新则分别遵循无变更走 minor、有变更走 major的版本矩阵规则和改版本号 npm run import-typescript 适配新 API的三步闭环。【免费下载链接】monaco-editorA browser based code editor项目地址: https://gitcode.com/gh_mirrors/mo/monaco-editor创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考