Extension.js 4.0.0 发布

​

唯一的破坏性变更是 Node.js

​

v4 带来什么

• 经典的多文件 content script 在开发模式下可以正常工作。当一个 content_scripts.js 数组列出多个普通文件时，Extension.js 会把它们拼接进浏览器本来会给它们的同一个共享作用域，把每个文件都注册为构建依赖，让任何一次保存都触发重建，并生成一个指向你真实文件和行号的 source map，而不是一个内联的大块。
• 更快的 Safari 开发。extension dev --browser=safari 在后台重新同步，而不是每次保存都阻塞在一次完整的 Xcode 构建上，一连串保存会合并为针对最新输出的一次重建。
• 不再泄漏浏览器。自行退出的开发会话现在会通过一条共享的销毁路径关闭浏览器，Chrome 和 Firefox 进程不会在你结束工作后继续滞留。
• 新增六个可按名称指定的浏览器：Brave、Opera、Vivaldi、Yandex、Waterfox 和 LibreWolf，此外还有面向自定义二进制的 chromium-based 与 gecko-based 目标。分支浏览器会继承其引擎家族的 chrome: 与 firefox: manifest 键，所以分支目标不需要自己的前缀。
• 不启动浏览器也能重载。extension dev --no-browser 现在也会重载 content script，走的是已启动浏览器所用的同一条 service worker 路径，这让它成为持续集成(CI)、容器和远程机器上的一个真正可用的选项。
• 靠得住的配置文件控制。profile: false、copyFromProfile 与 keepProfileChanges 从配置一路生效到 Chromium 和 Firefox 两个启动器，在 BrowserConfig 上有类型定义，被保留的配置文件也不会再被后续运行覆盖。
• 两个开发会话不再争抢同一个调试端口，因为 Chrome DevTools Protocol (CDP) 和 Remote Debugging Protocol (RDP) 端口现在按浏览器实例解析。
• 失败更响亮、代价更低。阻止产出的编译错误以非零退出，针对 Chromium 目标的 Manifest V2 构建会警告，缺失的 CSS url() 资产会警告并把 URL 原样传递而不是让构建失败，缺失的可选依赖会打印一条感知包管理器的安装提示，而不是一大段原始 JSON。
• Windows 上的 content script 路径会被规范化，loader 匹配和 content script 包装的行为与 macOS 和 Linux 一致。

​

第一天的流程没有变

npx extension@latest create my-extension
cd my-extension
npm run dev

​

升级提示

• 迁移到 Node.js 22.12 或更新版本，然后把这个包更新到最新版，
• 保持你的 extension.config.js 原样，因为没有需要跟进的 API 变更，
• 如果你曾经通过把多文件 content script 内联进一个文件来绕过问题，现在可以把它们拆回去了。

​

4.0 之后落地了什么

​

感谢