管理包

本仓库使用 npm workspaces 来管理 WordPress 软件包，并使用 lerna 将它们发布到 npm。这会在工作流程中强制执行某些步骤，这些步骤在 packages 文档中有详细介绍。

维护数十个 npm 软件包十分困难——很难追踪其中的变更。这正是我们为每个软件包使用 CHANGELOG.md 文件来简化发布流程的原因。作为贡献者，每当你贡献生产代码时，都应按照 维护变更日志 章节中的说明，在上述文件中添加一条记录。

将 WordPress 软件包发布到 npm 的操作已实现自动化，即与每两周一次的 Gutenberg 插件 RC1 版本发布同步进行。你可以在 Gutenberg 发布流程文档 中详细了解此流程以及其他发布 npm 软件包新版本的方式。

内部工作区（工具与测试）

本仓库还在 tools/ 和 test/ 下包含用于开发工具和测试基础设施的内部工作区。当你需要为仓库级工作添加新的工具、脚本或依赖时，请在 tools/ 下创建一个工作区（或添加到现有工作区中），而不是将依赖添加到根 package.json 中。有关转换模式、CI 约定和参考示例，请参阅 工作区开发指南。

供应链策略

.npmrc 选择启用了 npm v12 中拒绝 git 引用（EALLOWGIT）和 tarball URL（EALLOWREMOTE）的默认设置，并将这一限制扩展到本地 tarball 文件（EALLOWFILE）。本地目录则保持 npm 的默认行为，在此处不会限制任何内容：工作区之间的 file: 链接会被解析为工作区，而不是目录依赖。

安装脚本采用选择性启用机制：每个自带安装脚本的依赖都会被记录在根 package.json 的 allowScripts 中，而 strict-allow-scripts 对于未列入该列表的任何依赖，都会以 ESTRICTALLOWSCRIPTS 使安装失败。每个条目均为 false，因此安装时不会编译任何内容。test/ai-development 使用 --prefix 进行安装，因此它自带一份该策略的副本。

allowScripts 仅覆盖依赖项，因此 @wordpress/icons 的 prepare 等工作区生命周期脚本仍会运行。npm v12 在 install-strategy=linked 下会跳过这些脚本且不报错（npm/cli#9982），因此迁移到 npm v12 意味着需要改为从根 postinstall 中调用它们。

当安装以这种方式失败时，请阅读该脚本，然后手动编辑 allowScripts 并提交对 package.json 的更改。仅使用软件包名称即可覆盖其所有版本，或使用 name@version 将批准锁定在你所审查的版本：

"allowScripts": {
    "some-package": false,
    "another-package@1.2.3": true
}

在 npm 发布包含 npm/cli#9941 的版本之前，请勿使用 npm install-scripts 子命令。这些子命令都读取提升式（hoisted）布局，因此在 install-strategy=linked 下它们会行为异常：ls 会将已覆盖的软件包报告为未覆盖，prune 会将每个条目都当作未使用而删除，而 approve 和 deny 写入的是无法使用的 node_modules/.store 路径，而不是软件包名称。