尧图网站建设 
Nx 23 迁移指南将nx/expo的createNodesV2导入迁移为createNodes【免费下载链接】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 仓库中nx/expo插件的一次命名收敛迁移插件的主推断导出inferred-plugin export由createNodesV2更名为createNodes旧名称仅作为已弃用的别名保留。文章将说明迁移的触发场景、自动改写规则、可安全保留的写法并结合packages/expo下的迁移实现源码与测试用例帮助你在升级到 Nx 23 时无痛完成nx/expo/plugin相关导入的迁移同时理解底层重写原理。背景为什么会有createNodesV2与createNodes两个名字Nx 通过“推断插件”inferred plugin在运行时扫描项目文件如 Expo 应用的app.json/app.config.js/app.config.ts并自动生成可执行目标targets。在nx/expo中这一能力最初以createNodesV2的名字对外暴露随着 Nx 对推断插件接口的标准化nx/expo将主推断导出统一更名为createNodes并把createNodesV2作为已弃用别名保留以兼容存量代码。在 plugins/plugin.ts 中可以看到两个名字的底层关系——createNodesV2与createNodes指向同一实现export const createNodes: CreateNodesExpoPluginOptions [ ... ]; export const createNodesV2 createNodes;而 plugin.ts 作为包的公开出口同时导出了createNodes、createNodesV2与ExpoPluginOptions。这意味着无论你现在用的是哪个名字运行时行为完全一致区别只在于命名是否跟随新规范——新代码应当使用createNodes。这条迁移是做什么的本次迁移对应的实现位于 migrate-create-nodes-v2-to-create-nodes.ts它会在整个 workspace 中扫描所有.ts、.tsx、.cts、.mts文件并将来自nx/expo/plugin的createNodesV2命名导入named imports与再导出re-exports改写为createNodes。迁移在 migrations.json 中以update-23-0-0-migrate-create-nodes-v2-import注册版本23.0.0-beta.24因此当你通过 Nx 的版本升级机制nx migrate从旧版本升级时它会作为 Nx 23.0.0 系列迁移之一自动执行无需手工逐个文件修改。自动改写的场景与前后对照最简单的命名导入迁移前import { createNodesV2 } from nx/expo/plugin;迁移后import { createNodes } from nx/expo/plugin;别名alias被保留createNodesV2 as cn会改写为createNodes as cn本地别名cn保持不变因此文件体中所有对cn的引用都无需变动import { createNodesV2 as cn } from nx/expo/plugin; // 迁移后 import { createNodes as cn } from nx/expo/plugin;冗余别名被折叠如果本来就写成了createNodesV2 as createNodes改写后会折叠为无别名的形式import { createNodesV2 as createNodes } from nx/expo/plugin; // 迁移后 import { createNodes } from nx/expo/plugin;重复绑定去重如果文件已经同时导入了createNodes与createNodesV2重命名会造成重复绑定迁移会自动丢弃冗余的createNodesV2import { createNodes, createNodesV2 } from nx/expo/plugin; // 迁移后 import { createNodes } from nx/expo/plugin;无论createNodesV2在前还是在后{ createNodesV2, createNodes }去重逻辑都成立多行书写形式的命名导入同样会被规整为单行去重结果这一点由 migrate-create-nodes-v2-to-create-nodes.spec.ts 中的多组测试用例逐一验证。其他同类场景迁移同样处理默认导入与命名导入混写import def, { createNodesV2 } from nx/expo/plugin中仅改写命名绑定默认绑定不受影响、import type声明、行内type修饰符import { type createNodesV2 }、命名再导出export { createNodesV2 } from nx/expo/plugin以及带别名的命名再导出export { createNodesV2 as cn } from nx/expo/plugin。孤立导入时文件体内的值引用也会被同步改写这是最容易踩坑的细节。当文件里是无别名的import { createNodesV2 }单独导入或与createNodes去重后本地绑定的名字发生了真实变化因此文件体中对该绑定的一切值引用也必须同步重命名否则会出现悬空引用dangling referenceimport { createNodesV2 } from nx/expo/plugin; export const plugin createNodesV2; // 迁移后 import { createNodes } from nx/expo/plugin; export const plugin createNodes;作为函数实参传入的用法同样会被改写addPlugin(graph, nx/expo/plugin, createNodesV2, {}); // 迁移后 addPlugin(graph, nx/expo/plugin, createNodes, {});对于对象字面量中的简写属性shorthand property改写器会展开为createNodesV2: createNodes以保留属性键export const plugins { createNodesV2 }; // 迁移后 export const plugins { createNodesV2: createNodes };需要强调的是带别名的导入如createNodesV2 as cn不会触发值引用改写——本地名字cn没有变文件体中的引用天然安全。值引用改写在 rewriteCreateNodesV2Imports 中通过collectValueUsageRewrites实现它会遍历 TypeScript 抽象语法树AST只重命名真正指向被改绑定名的标识符并谨慎排除属性访问、限定类型名、对象字面量键名以及遮蔽导入声明的变量/参数/函数/类声明名。什么不会被自动改写迁移遵循“最小侵入”原则以下形式一律保留不动旧名称通过createNodesV2运行时别名依然可用如果需要彻底清除弃用名称请手工修改命名空间导入import * as plugin from nx/expo/plugin后再plugin.createNodesV2动态导入const { createNodesV2 } await import(nx/expo/plugin)require(...)解构const { createNodesV2 } require(nx/expo/plugin)属性访问plugin.createNodesV2属于成员名而非绑定名export * from nx/expo/plugin无命名绑定可改写来自其他模块说明符的导入如import { createNodesV2 } from nx/other-plugin/plugin或相对路径./plugin均不在改写范围内目标模块说明符集合中只有nx/expo/plugin字符串与注释注释里的createNodesV2、字符串字面量createNodesV2都不会被触碰上述行为均有对应测试佐证见 spec 文件 中does not touch ...系列用例并且测试还验证了非 TypeScript 文件如.md文档不会被扫描改写不含弃用名称的文件保持原样。迁移的工程实现要点从源码可以进一步看清这条迁移的内部机制文件遍历迁移入口migrateCreateNodesV2ToCreateNodes(tree)调用visitNotIgnoredFiles遍历整个 workspace先按扩展名.ts/.tsx/.cts/.mts过滤再用original.includes(DEPRECATED_NAME)做快速短路检查只有命中才进入 AST 重写未变更的文件不会写回。AST 驱动通过ensurePackage按需加载typescript用ts.createSourceFile解析源码后仅遍历顶层语句中的ImportDeclaration与ExportDeclaration改写通过applyChangesToString拼接DeleteInsert的字符级变更完成模块说明符、import/export关键字、type修饰符与默认导入均保持不动。目标模块集合常量TARGET_SPECIFIERS目前只包含nx/expo/plugin一个入口集中管理“从哪个模块改写”的策略未来扩展入口只需调整该集合。结果反馈与格式化若有文件被改写迁移会通过logger.info输出类似Renamed createNodesV2 imports to createNodes in N file(s).的统计信息最后统一调用formatFiles保证改完的代码符合 prettier 风格。测试保障spec 文件 对纯函数rewriteCreateNodesV2Imports与整个迁移 runner 双轨覆盖前者覆盖别名、去重、多行、type-only、再导出、不同模块说明符等 20 余个边界场景后者验证迁移在模拟 workspace 中跨a.ts、b.tsx、c.cts、d.mts批量改写并跳过无关文件。如何执行这条迁移该迁移已注册在 migrations.json 的update-23-0-0-migrate-create-nodes-v2-import条目中属于23.0.0-beta.24版本。在真实项目中你无需手动运行——升级 Nx 23 时执行标准的迁移流程即可# 升级 Nx 相关包并生成迁移任务 nx migrate latest # 执行自动迁移会包含本次 createNodesV2 → createNodes 改写 nx migrate --run-migrations如果只想针对该迁移做验证也可以在临时分支上先跑一次nx migrate --run-migrations并检查 Git diff确认改写的文件范围与预期一致再提交。升级后的收尾检查迁移完成后建议做三项检查确认无遗漏的createNodesV2静态命名导入全局搜索createNodesV2剩余出现点应当只属于命名空间导入、动态导入、require解构、属性访问、字符串或注释——这些是迁移有意保留的。确认别名语义未变凡是改写为createNodes as cn的地方本地调用名仍是cn编译与运行时行为应完全等价有疑虑时对比迁移前后的 Git diff。跑一遍类型检查与测试createNodesV2与createNodes底层指向同一实现见 plugins/plugin.ts运行时行为无差异类型检查与现有测试通过即可放心合入。小结createNodesV2→createNodes是nx/expo在 Nx 23 中完成的命名收敛新代码统一使用createNodes旧名称保留为弃用别名。对应的自动迁移以 AST 为驱动精准改写来自nx/expo/plugin的静态命名导入与再导出处理别名保留、重复去重、值引用联动改写等边界情况同时对命名空间导入、动态导入、require解构等写法保持最小侵入。理解“改写什么、不改写什么”你就能在升级后快速确认迁移结果让 workspace 平稳过渡到新命名规范。【免费下载链接】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 23 迁移指南：将 `@nx/expo` 的 `createNodesV2` 导入迁移为 `createNodes`
Nx 23 迁移指南将nx/expo的createNodesV2导入迁移为createNodes【免费下载链接】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 仓库中nx/expo插件的一次命名收敛迁移插件的主推断导出inferred-plugin export由createNodesV2更名为createNodes旧名称仅作为已弃用的别名保留。文章将说明迁移的触发场景、自动改写规则、可安全保留的写法并结合packages/expo下的迁移实现源码与测试用例帮助你在升级到 Nx 23 时无痛完成nx/expo/plugin相关导入的迁移同时理解底层重写原理。背景为什么会有createNodesV2与createNodes两个名字Nx 通过“推断插件”inferred plugin在运行时扫描项目文件如 Expo 应用的app.json/app.config.js/app.config.ts并自动生成可执行目标targets。在nx/expo中这一能力最初以createNodesV2的名字对外暴露随着 Nx 对推断插件接口的标准化nx/expo将主推断导出统一更名为createNodes并把createNodesV2作为已弃用别名保留以兼容存量代码。在 plugins/plugin.ts 中可以看到两个名字的底层关系——createNodesV2与createNodes指向同一实现export const createNodes: CreateNodesExpoPluginOptions [ ... ]; export const createNodesV2 createNodes;而 plugin.ts 作为包的公开出口同时导出了createNodes、createNodesV2与ExpoPluginOptions。这意味着无论你现在用的是哪个名字运行时行为完全一致区别只在于命名是否跟随新规范——新代码应当使用createNodes。这条迁移是做什么的本次迁移对应的实现位于 migrate-create-nodes-v2-to-create-nodes.ts它会在整个 workspace 中扫描所有.ts、.tsx、.cts、.mts文件并将来自nx/expo/plugin的createNodesV2命名导入named imports与再导出re-exports改写为createNodes。迁移在 migrations.json 中以update-23-0-0-migrate-create-nodes-v2-import注册版本23.0.0-beta.24因此当你通过 Nx 的版本升级机制nx migrate从旧版本升级时它会作为 Nx 23.0.0 系列迁移之一自动执行无需手工逐个文件修改。自动改写的场景与前后对照最简单的命名导入迁移前import { createNodesV2 } from nx/expo/plugin;迁移后import { createNodes } from nx/expo/plugin;别名alias被保留createNodesV2 as cn会改写为createNodes as cn本地别名cn保持不变因此文件体中所有对cn的引用都无需变动import { createNodesV2 as cn } from nx/expo/plugin; // 迁移后 import { createNodes as cn } from nx/expo/plugin;冗余别名被折叠如果本来就写成了createNodesV2 as createNodes改写后会折叠为无别名的形式import { createNodesV2 as createNodes } from nx/expo/plugin; // 迁移后 import { createNodes } from nx/expo/plugin;重复绑定去重如果文件已经同时导入了createNodes与createNodesV2重命名会造成重复绑定迁移会自动丢弃冗余的createNodesV2import { createNodes, createNodesV2 } from nx/expo/plugin; // 迁移后 import { createNodes } from nx/expo/plugin;无论createNodesV2在前还是在后{ createNodesV2, createNodes }去重逻辑都成立多行书写形式的命名导入同样会被规整为单行去重结果这一点由 migrate-create-nodes-v2-to-create-nodes.spec.ts 中的多组测试用例逐一验证。其他同类场景迁移同样处理默认导入与命名导入混写import def, { createNodesV2 } from nx/expo/plugin中仅改写命名绑定默认绑定不受影响、import type声明、行内type修饰符import { type createNodesV2 }、命名再导出export { createNodesV2 } from nx/expo/plugin以及带别名的命名再导出export { createNodesV2 as cn } from nx/expo/plugin。孤立导入时文件体内的值引用也会被同步改写这是最容易踩坑的细节。当文件里是无别名的import { createNodesV2 }单独导入或与createNodes去重后本地绑定的名字发生了真实变化因此文件体中对该绑定的一切值引用也必须同步重命名否则会出现悬空引用dangling referenceimport { createNodesV2 } from nx/expo/plugin; export const plugin createNodesV2; // 迁移后 import { createNodes } from nx/expo/plugin; export const plugin createNodes;作为函数实参传入的用法同样会被改写addPlugin(graph, nx/expo/plugin, createNodesV2, {}); // 迁移后 addPlugin(graph, nx/expo/plugin, createNodes, {});对于对象字面量中的简写属性shorthand property改写器会展开为createNodesV2: createNodes以保留属性键export const plugins { createNodesV2 }; // 迁移后 export const plugins { createNodesV2: createNodes };需要强调的是带别名的导入如createNodesV2 as cn不会触发值引用改写——本地名字cn没有变文件体中的引用天然安全。值引用改写在 rewriteCreateNodesV2Imports 中通过collectValueUsageRewrites实现它会遍历 TypeScript 抽象语法树AST只重命名真正指向被改绑定名的标识符并谨慎排除属性访问、限定类型名、对象字面量键名以及遮蔽导入声明的变量/参数/函数/类声明名。什么不会被自动改写迁移遵循“最小侵入”原则以下形式一律保留不动旧名称通过createNodesV2运行时别名依然可用如果需要彻底清除弃用名称请手工修改命名空间导入import * as plugin from nx/expo/plugin后再plugin.createNodesV2动态导入const { createNodesV2 } await import(nx/expo/plugin)require(...)解构const { createNodesV2 } require(nx/expo/plugin)属性访问plugin.createNodesV2属于成员名而非绑定名export * from nx/expo/plugin无命名绑定可改写来自其他模块说明符的导入如import { createNodesV2 } from nx/other-plugin/plugin或相对路径./plugin均不在改写范围内目标模块说明符集合中只有nx/expo/plugin字符串与注释注释里的createNodesV2、字符串字面量createNodesV2都不会被触碰上述行为均有对应测试佐证见 spec 文件 中does not touch ...系列用例并且测试还验证了非 TypeScript 文件如.md文档不会被扫描改写不含弃用名称的文件保持原样。迁移的工程实现要点从源码可以进一步看清这条迁移的内部机制文件遍历迁移入口migrateCreateNodesV2ToCreateNodes(tree)调用visitNotIgnoredFiles遍历整个 workspace先按扩展名.ts/.tsx/.cts/.mts过滤再用original.includes(DEPRECATED_NAME)做快速短路检查只有命中才进入 AST 重写未变更的文件不会写回。AST 驱动通过ensurePackage按需加载typescript用ts.createSourceFile解析源码后仅遍历顶层语句中的ImportDeclaration与ExportDeclaration改写通过applyChangesToString拼接DeleteInsert的字符级变更完成模块说明符、import/export关键字、type修饰符与默认导入均保持不动。目标模块集合常量TARGET_SPECIFIERS目前只包含nx/expo/plugin一个入口集中管理“从哪个模块改写”的策略未来扩展入口只需调整该集合。结果反馈与格式化若有文件被改写迁移会通过logger.info输出类似Renamed createNodesV2 imports to createNodes in N file(s).的统计信息最后统一调用formatFiles保证改完的代码符合 prettier 风格。测试保障spec 文件 对纯函数rewriteCreateNodesV2Imports与整个迁移 runner 双轨覆盖前者覆盖别名、去重、多行、type-only、再导出、不同模块说明符等 20 余个边界场景后者验证迁移在模拟 workspace 中跨a.ts、b.tsx、c.cts、d.mts批量改写并跳过无关文件。如何执行这条迁移该迁移已注册在 migrations.json 的update-23-0-0-migrate-create-nodes-v2-import条目中属于23.0.0-beta.24版本。在真实项目中你无需手动运行——升级 Nx 23 时执行标准的迁移流程即可# 升级 Nx 相关包并生成迁移任务 nx migrate latest # 执行自动迁移会包含本次 createNodesV2 → createNodes 改写 nx migrate --run-migrations如果只想针对该迁移做验证也可以在临时分支上先跑一次nx migrate --run-migrations并检查 Git diff确认改写的文件范围与预期一致再提交。升级后的收尾检查迁移完成后建议做三项检查确认无遗漏的createNodesV2静态命名导入全局搜索createNodesV2剩余出现点应当只属于命名空间导入、动态导入、require解构、属性访问、字符串或注释——这些是迁移有意保留的。确认别名语义未变凡是改写为createNodes as cn的地方本地调用名仍是cn编译与运行时行为应完全等价有疑虑时对比迁移前后的 Git diff。跑一遍类型检查与测试createNodesV2与createNodes底层指向同一实现见 plugins/plugin.ts运行时行为无差异类型检查与现有测试通过即可放心合入。小结createNodesV2→createNodes是nx/expo在 Nx 23 中完成的命名收敛新代码统一使用createNodes旧名称保留为弃用别名。对应的自动迁移以 AST 为驱动精准改写来自nx/expo/plugin的静态命名导入与再导出处理别名保留、重复去重、值引用联动改写等边界情况同时对命名空间导入、动态导入、require解构等写法保持最小侵入。理解“改写什么、不改写什么”你就能在升级后快速确认迁移结果让 workspace 平稳过渡到新命名规范。【免费下载链接】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），仅供参考