Nx 21.0.0 迁移指南将nx/gradle插件切换为nx/gradle/plugin-v1【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx本篇迁移指南面向所有在 Nx 仓库中使用 Gradle 的开发者讲解 Nx 21.0.0 中一项自动迁移migration的具体内容将nx.json中注册的nx/gradle插件更改为nx/gradle/plugin-v1。文章不仅给出迁移前后完整的配置对照还会深入仓库源码解释迁移器内部如何处理两种插件声明形式、如何安全跳过无关仓库以及这一变更与后续plugin-v1弃用、atomized targets 演进之间的关联。读完本文你将能够理解该迁移的触发机制、手动执行与验证方法并掌握nx.json中插件条目的声明细节。迁移背景为什么 Nx 21 需要切换 Gradle 插件入口Nx 的迁移系统由nx migrate命令驱动会在升级主版本时自动调整工作区配置。在 Nx 21.0.0 中nx/gradle包将插件的注册入口迁移到了新路径nx/gradle/plugin-v1迁移名称为change-plugin-to-v1其官方描述即为Change nx/gradle plugin to version 1将nx/gradle插件更改为版本 1。这条迁移的注册信息可以在 packages/gradle/migrations.json 中看到{ generators: { change-plugin-to-v1: { version: 21.0.0-beta.5, cli: nx, description: Change nx/gradle plugin to version 1, factory: ./dist/src/migrations/21-0-0/change-plugin-to-v1, documentation: ./dist/src/migrations/21-0-0/change-plugin-to-v1.md } } }version字段21.0.0-beta.5表示该迁移在 Nx 21.0.0-beta.5 及之后随升级自动执行factory指向迁移器的编译产物。也就是说从旧版本 Nx 升级到 21.x 时只要工作区中确实使用了 Gradle 插件nx migrate就会自动完成下文所述的配置替换迁移的完整说明文档正是 packages/gradle/src/migrations/21-0-0/change-plugin-to-v1.md。迁移内容nx.json中插件条目的变更该迁移只做一件事把nx.json中plugins数组里的nx/gradle替换为nx/gradle/plugin-v1其余配置一律不动。迁移前Before升级前工作区的nx.json通常以如下形式注册 Gradle 插件{ plugins: [nx/gradle] }迁移后After迁移完成后plugins数组中对应条目变为{ plugins: [nx/gradle/plugin-v1] }这是最简单的字符串形式。除此之外Nx 的plugins数组还支持带配置的对象形式见下文迁移器对两种形式都会正确处理。迁移器源码剖析两种声明形式都被覆盖迁移器的完整实现在 packages/gradle/src/migrations/21-0-0/change-plugin-to-v1.ts核心逻辑如下import { Tree, readNxJson, updateNxJson } from nx/devkit; import { hasGradlePlugin } from ../../utils/has-gradle-plugin; /* This function changes the plugin to v1 * Replace nx/gradle with nx/gradle/plugin-v1 */ export default function update(tree: Tree) { const nxJson readNxJson(tree); if (!nxJson) { return; } if (!hasGradlePlugin(tree)) { return; } let gradlePluginIndex nxJson.plugins.findIndex((p) typeof p string ? p nx/gradle : p.plugin nx/gradle ); let gradlePlugin nxJson.plugins[gradlePluginIndex]; if (typeof gradlePlugin string) { nxJson.plugins[gradlePluginIndex] nx/gradle/plugin-v1; } else { gradlePlugin.plugin nx/gradle/plugin-v1; } updateNxJson(tree, nxJson); }该实现体现了三条关键设计1. 空仓库安全退出。迁移器首先调用readNxJson(tree)读取工作区根nx.json若不存在则直接返回随后调用hasGradlePlugin(tree)检查插件是否注册若仓库根本没有 Gradle 插件迁移器不做任何修改。这是典型的幂等 最小改动迁移策略无关仓库升级 Nx 21 时不会产生任何配置噪声。2. 两种插件声明形式都兼容。Nx 的plugins数组中的元素既可以是纯字符串也可以是{ plugin: string, options: {...} }对象。findIndex中的三元表达式typeof p string ? p nx/gradle : p.plugin nx/gradle同时匹配这两种形式替换时也分别处理字符串形式nxJson.plugins[gradlePluginIndex] nx/gradle/plugin-v1对象形式仅修改gradlePlugin.plugin字段保留options等其余属性不变。对象形式在带自定义选项的工作区中非常常见例如{ plugins: [ { plugin: nx/gradle, options: { testTargetName: test } } ] }迁移后plugin字段被替换options原样保留{ plugins: [ { plugin: nx/gradle/plugin-v1, options: { testTargetName: test } } ] }3. 通过updateNxJson原子写回。最后调用updateNxJson(tree, nxJson)将修改后的配置写回nx.json保证整个变更在一个事务内完成配合 Nx 迁移系统的文件变更跟踪用户可以在nx migrate完成后检查生成的迁移文件再决定是否应用。辅助函数hasGradlePlugin前置检查逻辑被提取为独立的工具函数 packages/gradle/src/utils/has-gradle-plugin.ts它同样兼容两种插件声明形式import { readNxJson, Tree } from nx/devkit; export function hasGradlePlugin(tree: Tree): boolean { const nxJson readNxJson(tree); return !!nxJson.plugins?.some((p) typeof p string ? p nx/gradle : p.plugin nx/gradle ); }注意这里使用了plugins?.some(...)可选链即使nx.json中没有plugins字段也不会抛错而是返回false让迁移器直接跳过。测试用例验证迁移行为的三种场景仓库为该迁移编写了完整的单元测试见 packages/gradle/src/migrations/21-0-0/change-plugin-to-v1.spec.ts测试基于nx/devkit/testing提供的createTreeWithEmptyWorkspace()虚拟文件树覆盖了三个典型场景场景一仓库未注册 Gradle 插件时不做任何修改。测试构造只有namedInputs的nx.json执行迁移后快照断言配置原样保留it(should not add nx/gradle plugin if it does not exist, async () { tree.write(nx.json, JSON.stringify({ namedInputs: {} })); update(tree); expect(readNxJson(tree)).toMatchInlineSnapshot( { namedInputs: {}, } ); });场景二字符串形式插件被正确替换。这是最常见的情况it(should change nx/gradle to nx/gradle/plugin-v1 plugin, async () { tree.write(nx.json, JSON.stringify({ plugins: [nx/gradle] })); update(tree); expect(readNxJson(tree)).toMatchInlineSnapshot( { plugins: [ nx/gradle/plugin-v1, ], } ); });场景三带options的对象形式插件仅替换插件名、保留选项。该用例验证了{ plugin, options }形式下选项不会丢失it(should change nx/gradle plugin name with options, async () { tree.write( nx.json, JSON.stringify({ plugins: [ { plugin: nx/gradle, options: { testTargetName: test } }, ], }) ); update(tree); expect(readNxJson(tree)).toMatchInlineSnapshot( { plugins: [ { options: { testTargetName: test, }, plugin: nx/gradle/plugin-v1, }, ], } ); });这三个用例从不同角度锁定了迁移器的行为契约不误改无关仓库、正确替换字符串形式、对象形式保留配置选项。执行与验证手动应用该迁移虽然nx migrate会在升级到 Nx 21 时自动应用这条迁移但如果你希望单独执行或事后验证可以参考以下方式。1. 通过nx migrate全量升级在项目根目录运行nx migrate latest升级流程会先更新依赖然后生成针对当前版本的迁移文件包括change-plugin-to-v1执行后nx.json中的nx/gradle会被自动替换为nx/gradle/plugin-v1。也可以在升级后单独运行nx migrate --run-migrationsmigrations.json2. 手动修改等价操作不想依赖自动迁移时直接编辑nx.json将plugins: [nx/gradle]改为plugins: [nx/gradle/plugin-v1]若为对象形式仅将plugin: nx/gradle改为plugin: nx/gradle/plugin-v1options保持不变。3. 验证结果修改完成后运行以下命令验证插件加载与项目图谱生成正常nx graph nx show projects同时可以用nx migrate生成的结果确认迁移记录已应用。若nx graph能正常渲染出 Gradle 项目节点、nx show projects能列出各 Gradle 子项目则说明plugin-v1入口已正确接管项目发现与依赖推断。进一步理解plugin-v1 与后续演进plugin-v1 入口的实现与弃用状态nx/gradle/plugin-v1是对旧版nx/gradle插件行为的 v1 化封装其入口实现在 packages/gradle/plugin-v1.ts。值得注意的是该文件顶部带有一条运行时告警if (typeof emitPluginWorkerLog function) { emitPluginWorkerLog( warn, nx/gradle/plugin-v1 is deprecated and will be removed in Nx 24. Switch your nx.json plugins entry from nx/gradle/plugin-v1 to nx/gradle. Note that the default nx/gradle plugin generates atomized targets — see https://nx.dev/nx-api/gradle for configuration options. ); }也就是说plugin-v1本身是一个过渡性入口它从 Nx 21 起作为nx/gradle的 v1 形态存在但官方已明确其将于 Nx 24 移除并建议用户切回默认的nx/gradle插件——此时默认入口生成的是atomized targets原子化目标即按 Gradle 任务粒度拆分出更细粒度的 Nx target。入口通过emitPluginWorkerLog输出告警是为了让警告在 Nx daemon 启用时也能传递给用户logger.warn会被路由到 daemon 日志文件而静默吞掉。与此同时新版默认插件 packages/gradle/plugin.ts 导出了createNodes/createDependencies并通过NX_GRADLE_DISABLEtrue环境变量支持整体禁用const isDisabled process.env.NX_GRADLE_DISABLE true; export const name isDisabled ? nx/gradle [disabled] : nx/gradle; export const createNodes isDisabled ? undefined : _createNodes; /** * deprecated Use {link createNodes} instead. This will be removed in Nx 24. */ export const createNodesV2 createNodes; export const createDependencies isDisabled ? undefined : _createDependencies;createNodesV2已被标记为弃用并指向createNodes这与迁移update-23-0-0-migrate-create-nodes-v2-import见 packages/gradle/migrations.json中将createNodesV2导入重命名为规范的createNodes的演进方向一致。同一版本内的配套迁移Nx 21.0.0 的 Gradle 迁移并非只有插件入口变更一项。紧随其后的21.0.0-beta.13还提供了change-ciTargetName-to-ciTestTargetName迁移将插件选项ciTargetName重命名为ciTestTargetName其说明文档见 packages/gradle/src/migrations/21-0-0/change-ciTargetName-to-ciTestTargetName.md{ plugins: [ plugin: nx/gradle, options: { ciTargetName: ci } ] }{ plugins: [ plugin: nx/gradle, options: { ciTestTargetName: ci } ] }该迁移只重命名选项键不改变插件入口与change-plugin-to-v1相互独立、可叠加执行。迁移链全景从 21 到 23 的 Gradle 插件演进如果将视角拉远change-plugin-to-v1只是整个 Gradle 插件演进链条中的一环。从 packages/gradle/migrations.json 的注册记录可以看出完整脉络Nx 21.0.0插件入口从nx/gradle切换到nx/gradle/plugin-v1随后选项ciTargetName更名为ciTestTargetNameNx 21.1.2 → 23.2.0一系列change-plugin-version-0-1-x迁移持续升级 Gradle 侧dev.nx.gradle.project-graph插件的版本从 0.1.0 一直到 0.1.25保证 Nx 与 Gradle 插件协议同步演进Nx 23.0.0update-23-0-0-migrate-create-nodes-v2-import将createNodesV2导入规范化为createNodes为最终统一入口做准备Nx 24规划移除nx/gradle/plugin-v1默认nx/gradle以 atomized targets 形态承载 Gradle 集成。因此如果你当前仍在使用nx/gradle/plugin-v1建议尽早规划切回默认nx/gradle以避免未来大版本升级时再次经历入口迁移。小结change-plugin-to-v1是一条小而关键的 Nx 21.0.0 迁移它将nx.json中的nx/gradle替换为nx/gradle/plugin-v1兼容字符串与带options的对象两种插件声明形式并通过前置检查确保未使用 Gradle 的仓库零改动。其实现change-plugin-to-v1.ts、辅助函数has-gradle-plugin.ts与三组单元测试change-plugin-to-v1.spec.ts共同构成了可验证的行为契约。理解这条迁移是掌握 Nx Gradle 插件从 v0 到 v1 再到 atomized v2 演进路线的第一步。【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nx 21.0.0 迁移指南：将 `@nx/gradle` 插件切换为 `@nx/gradle/plugin-v1`
Nx 21.0.0 迁移指南将nx/gradle插件切换为nx/gradle/plugin-v1【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx本篇迁移指南面向所有在 Nx 仓库中使用 Gradle 的开发者讲解 Nx 21.0.0 中一项自动迁移migration的具体内容将nx.json中注册的nx/gradle插件更改为nx/gradle/plugin-v1。文章不仅给出迁移前后完整的配置对照还会深入仓库源码解释迁移器内部如何处理两种插件声明形式、如何安全跳过无关仓库以及这一变更与后续plugin-v1弃用、atomized targets 演进之间的关联。读完本文你将能够理解该迁移的触发机制、手动执行与验证方法并掌握nx.json中插件条目的声明细节。迁移背景为什么 Nx 21 需要切换 Gradle 插件入口Nx 的迁移系统由nx migrate命令驱动会在升级主版本时自动调整工作区配置。在 Nx 21.0.0 中nx/gradle包将插件的注册入口迁移到了新路径nx/gradle/plugin-v1迁移名称为change-plugin-to-v1其官方描述即为Change nx/gradle plugin to version 1将nx/gradle插件更改为版本 1。这条迁移的注册信息可以在 packages/gradle/migrations.json 中看到{ generators: { change-plugin-to-v1: { version: 21.0.0-beta.5, cli: nx, description: Change nx/gradle plugin to version 1, factory: ./dist/src/migrations/21-0-0/change-plugin-to-v1, documentation: ./dist/src/migrations/21-0-0/change-plugin-to-v1.md } } }version字段21.0.0-beta.5表示该迁移在 Nx 21.0.0-beta.5 及之后随升级自动执行factory指向迁移器的编译产物。也就是说从旧版本 Nx 升级到 21.x 时只要工作区中确实使用了 Gradle 插件nx migrate就会自动完成下文所述的配置替换迁移的完整说明文档正是 packages/gradle/src/migrations/21-0-0/change-plugin-to-v1.md。迁移内容nx.json中插件条目的变更该迁移只做一件事把nx.json中plugins数组里的nx/gradle替换为nx/gradle/plugin-v1其余配置一律不动。迁移前Before升级前工作区的nx.json通常以如下形式注册 Gradle 插件{ plugins: [nx/gradle] }迁移后After迁移完成后plugins数组中对应条目变为{ plugins: [nx/gradle/plugin-v1] }这是最简单的字符串形式。除此之外Nx 的plugins数组还支持带配置的对象形式见下文迁移器对两种形式都会正确处理。迁移器源码剖析两种声明形式都被覆盖迁移器的完整实现在 packages/gradle/src/migrations/21-0-0/change-plugin-to-v1.ts核心逻辑如下import { Tree, readNxJson, updateNxJson } from nx/devkit; import { hasGradlePlugin } from ../../utils/has-gradle-plugin; /* This function changes the plugin to v1 * Replace nx/gradle with nx/gradle/plugin-v1 */ export default function update(tree: Tree) { const nxJson readNxJson(tree); if (!nxJson) { return; } if (!hasGradlePlugin(tree)) { return; } let gradlePluginIndex nxJson.plugins.findIndex((p) typeof p string ? p nx/gradle : p.plugin nx/gradle ); let gradlePlugin nxJson.plugins[gradlePluginIndex]; if (typeof gradlePlugin string) { nxJson.plugins[gradlePluginIndex] nx/gradle/plugin-v1; } else { gradlePlugin.plugin nx/gradle/plugin-v1; } updateNxJson(tree, nxJson); }该实现体现了三条关键设计1. 空仓库安全退出。迁移器首先调用readNxJson(tree)读取工作区根nx.json若不存在则直接返回随后调用hasGradlePlugin(tree)检查插件是否注册若仓库根本没有 Gradle 插件迁移器不做任何修改。这是典型的幂等 最小改动迁移策略无关仓库升级 Nx 21 时不会产生任何配置噪声。2. 两种插件声明形式都兼容。Nx 的plugins数组中的元素既可以是纯字符串也可以是{ plugin: string, options: {...} }对象。findIndex中的三元表达式typeof p string ? p nx/gradle : p.plugin nx/gradle同时匹配这两种形式替换时也分别处理字符串形式nxJson.plugins[gradlePluginIndex] nx/gradle/plugin-v1对象形式仅修改gradlePlugin.plugin字段保留options等其余属性不变。对象形式在带自定义选项的工作区中非常常见例如{ plugins: [ { plugin: nx/gradle, options: { testTargetName: test } } ] }迁移后plugin字段被替换options原样保留{ plugins: [ { plugin: nx/gradle/plugin-v1, options: { testTargetName: test } } ] }3. 通过updateNxJson原子写回。最后调用updateNxJson(tree, nxJson)将修改后的配置写回nx.json保证整个变更在一个事务内完成配合 Nx 迁移系统的文件变更跟踪用户可以在nx migrate完成后检查生成的迁移文件再决定是否应用。辅助函数hasGradlePlugin前置检查逻辑被提取为独立的工具函数 packages/gradle/src/utils/has-gradle-plugin.ts它同样兼容两种插件声明形式import { readNxJson, Tree } from nx/devkit; export function hasGradlePlugin(tree: Tree): boolean { const nxJson readNxJson(tree); return !!nxJson.plugins?.some((p) typeof p string ? p nx/gradle : p.plugin nx/gradle ); }注意这里使用了plugins?.some(...)可选链即使nx.json中没有plugins字段也不会抛错而是返回false让迁移器直接跳过。测试用例验证迁移行为的三种场景仓库为该迁移编写了完整的单元测试见 packages/gradle/src/migrations/21-0-0/change-plugin-to-v1.spec.ts测试基于nx/devkit/testing提供的createTreeWithEmptyWorkspace()虚拟文件树覆盖了三个典型场景场景一仓库未注册 Gradle 插件时不做任何修改。测试构造只有namedInputs的nx.json执行迁移后快照断言配置原样保留it(should not add nx/gradle plugin if it does not exist, async () { tree.write(nx.json, JSON.stringify({ namedInputs: {} })); update(tree); expect(readNxJson(tree)).toMatchInlineSnapshot( { namedInputs: {}, } ); });场景二字符串形式插件被正确替换。这是最常见的情况it(should change nx/gradle to nx/gradle/plugin-v1 plugin, async () { tree.write(nx.json, JSON.stringify({ plugins: [nx/gradle] })); update(tree); expect(readNxJson(tree)).toMatchInlineSnapshot( { plugins: [ nx/gradle/plugin-v1, ], } ); });场景三带options的对象形式插件仅替换插件名、保留选项。该用例验证了{ plugin, options }形式下选项不会丢失it(should change nx/gradle plugin name with options, async () { tree.write( nx.json, JSON.stringify({ plugins: [ { plugin: nx/gradle, options: { testTargetName: test } }, ], }) ); update(tree); expect(readNxJson(tree)).toMatchInlineSnapshot( { plugins: [ { options: { testTargetName: test, }, plugin: nx/gradle/plugin-v1, }, ], } ); });这三个用例从不同角度锁定了迁移器的行为契约不误改无关仓库、正确替换字符串形式、对象形式保留配置选项。执行与验证手动应用该迁移虽然nx migrate会在升级到 Nx 21 时自动应用这条迁移但如果你希望单独执行或事后验证可以参考以下方式。1. 通过nx migrate全量升级在项目根目录运行nx migrate latest升级流程会先更新依赖然后生成针对当前版本的迁移文件包括change-plugin-to-v1执行后nx.json中的nx/gradle会被自动替换为nx/gradle/plugin-v1。也可以在升级后单独运行nx migrate --run-migrationsmigrations.json2. 手动修改等价操作不想依赖自动迁移时直接编辑nx.json将plugins: [nx/gradle]改为plugins: [nx/gradle/plugin-v1]若为对象形式仅将plugin: nx/gradle改为plugin: nx/gradle/plugin-v1options保持不变。3. 验证结果修改完成后运行以下命令验证插件加载与项目图谱生成正常nx graph nx show projects同时可以用nx migrate生成的结果确认迁移记录已应用。若nx graph能正常渲染出 Gradle 项目节点、nx show projects能列出各 Gradle 子项目则说明plugin-v1入口已正确接管项目发现与依赖推断。进一步理解plugin-v1 与后续演进plugin-v1 入口的实现与弃用状态nx/gradle/plugin-v1是对旧版nx/gradle插件行为的 v1 化封装其入口实现在 packages/gradle/plugin-v1.ts。值得注意的是该文件顶部带有一条运行时告警if (typeof emitPluginWorkerLog function) { emitPluginWorkerLog( warn, nx/gradle/plugin-v1 is deprecated and will be removed in Nx 24. Switch your nx.json plugins entry from nx/gradle/plugin-v1 to nx/gradle. Note that the default nx/gradle plugin generates atomized targets — see https://nx.dev/nx-api/gradle for configuration options. ); }也就是说plugin-v1本身是一个过渡性入口它从 Nx 21 起作为nx/gradle的 v1 形态存在但官方已明确其将于 Nx 24 移除并建议用户切回默认的nx/gradle插件——此时默认入口生成的是atomized targets原子化目标即按 Gradle 任务粒度拆分出更细粒度的 Nx target。入口通过emitPluginWorkerLog输出告警是为了让警告在 Nx daemon 启用时也能传递给用户logger.warn会被路由到 daemon 日志文件而静默吞掉。与此同时新版默认插件 packages/gradle/plugin.ts 导出了createNodes/createDependencies并通过NX_GRADLE_DISABLEtrue环境变量支持整体禁用const isDisabled process.env.NX_GRADLE_DISABLE true; export const name isDisabled ? nx/gradle [disabled] : nx/gradle; export const createNodes isDisabled ? undefined : _createNodes; /** * deprecated Use {link createNodes} instead. This will be removed in Nx 24. */ export const createNodesV2 createNodes; export const createDependencies isDisabled ? undefined : _createDependencies;createNodesV2已被标记为弃用并指向createNodes这与迁移update-23-0-0-migrate-create-nodes-v2-import见 packages/gradle/migrations.json中将createNodesV2导入重命名为规范的createNodes的演进方向一致。同一版本内的配套迁移Nx 21.0.0 的 Gradle 迁移并非只有插件入口变更一项。紧随其后的21.0.0-beta.13还提供了change-ciTargetName-to-ciTestTargetName迁移将插件选项ciTargetName重命名为ciTestTargetName其说明文档见 packages/gradle/src/migrations/21-0-0/change-ciTargetName-to-ciTestTargetName.md{ plugins: [ plugin: nx/gradle, options: { ciTargetName: ci } ] }{ plugins: [ plugin: nx/gradle, options: { ciTestTargetName: ci } ] }该迁移只重命名选项键不改变插件入口与change-plugin-to-v1相互独立、可叠加执行。迁移链全景从 21 到 23 的 Gradle 插件演进如果将视角拉远change-plugin-to-v1只是整个 Gradle 插件演进链条中的一环。从 packages/gradle/migrations.json 的注册记录可以看出完整脉络Nx 21.0.0插件入口从nx/gradle切换到nx/gradle/plugin-v1随后选项ciTargetName更名为ciTestTargetNameNx 21.1.2 → 23.2.0一系列change-plugin-version-0-1-x迁移持续升级 Gradle 侧dev.nx.gradle.project-graph插件的版本从 0.1.0 一直到 0.1.25保证 Nx 与 Gradle 插件协议同步演进Nx 23.0.0update-23-0-0-migrate-create-nodes-v2-import将createNodesV2导入规范化为createNodes为最终统一入口做准备Nx 24规划移除nx/gradle/plugin-v1默认nx/gradle以 atomized targets 形态承载 Gradle 集成。因此如果你当前仍在使用nx/gradle/plugin-v1建议尽早规划切回默认nx/gradle以避免未来大版本升级时再次经历入口迁移。小结change-plugin-to-v1是一条小而关键的 Nx 21.0.0 迁移它将nx.json中的nx/gradle替换为nx/gradle/plugin-v1兼容字符串与带options的对象两种插件声明形式并通过前置检查确保未使用 Gradle 的仓库零改动。其实现change-plugin-to-v1.ts、辅助函数has-gradle-plugin.ts与三组单元测试change-plugin-to-v1.spec.ts共同构成了可验证的行为契约。理解这条迁移是掌握 Nx Gradle 插件从 v0 到 v1 再到 atomized v2 演进路线的第一步。【免费下载链接】nxThe Monorepo Platform that amplifies both developers and AI agents. Nx optimizes your builds, scales your CI, and fixes failed PRs automatically. Ship in half the time.项目地址: https://gitcode.com/GitHub_Trending/nx/nx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考