Nx nx import 实战指南将外部仓库与 Git 历史完整迁入 Monorepo【免费下载链接】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 import命令展开讲解如何把外部 Git 仓库或本地目录中的项目连同提交历史一起迁入当前工作区包括子目录导入与整仓导入两种策略的选择、目标目录约定、应用/库识别规则以及 pnpm 工作区 glob、根依赖合并、TypeScript 项目引用、ESLint 版本等十余类高频问题的排查与修复方法。读完后你可以独立完成多仓库 → Nx Monorepo的迁移并具备处理导入后构建、类型检查与测试失败的源码级定位能力。命令核心能力与完整参数nx import的作用是把源仓库或文件夹中的代码带入当前工作区并保留提交历史。命令签名与参数定义在 command-object.tsnx import [sourceRepository] [destinationDirectory]参数类型说明sourceRepository位置参数string源仓库的远程 URL 或本地路径destinationDirectory/--destination位置参数string当前工作区中的目标目录--sourcestring源仓库中要导入的子目录默认整仓--refstring要导入的分支或引用--depthnumber限制 clone 深度加快克隆速度--interactiveboolean交互模式默认true早期版本请始终用--no-interactive并直接指定所有参数--pluginsstring导入后安装的插件skip不装、all装全部检测到的、或逗号分隔列表如nx/vite,nx/jest--verboseboolean输出更详细的错误信息几条来自官方技能文档 SKILL.md 的快速须知运行nx import --help查看可用选项导入前必须保证目标目录为空——例如目标工作区已有libs/utils与libs/models源仓库有libs/ui与libs/data-access时不能把libs/直接整体导入libs/需要逐个导入源库nx22.6.0之后nx import面向 AI Agent 会以.ndjson形式输出进度与追问信息详见下文 Agent 模式一节早期版本则始终以非交互方式运行并直接指定全部 flag。导入流程的源码级拆解importHandler的完整实现位于 import.ts。从源码结构看一次导入实际经历以下步骤理解它对排查导入到一半失败非常关键前置检查目标仓库存在未提交改动时直接抛错——You have uncommitted changes in the destination repositoryimport.ts#L117-L121克隆源仓库到系统临时目录$TMPDIR/nx-import/repo可选--depth限制历史深度import.ts#L176-L193创建临时分支__nx_tmp_import__/ref并检出源分支import.ts#L250-L262历史过滤prepareSourceRepo把源仓库历史改写为源码始终位于目标路径的样子这是 Git 历史得以按目标目录保留的关键import.ts#L286-L293实现见 prepare-source-repo.ts合并进工作区把临时仓库注册为临时 remote 后执行 mergeimport.ts#L295-L311实现见 merge-remote-source.ts补写工作区条目若目标路径未被workspaces/packages覆盖自动把路径写进package.json或pnpm-workspace.yaml并 amend 提交import.ts#L733-L806安装依赖与插件执行安装、detectPlugins检测并安装插件、configurePlugins注册到nx.json每一步失败都不中断导入而是打印手动补救命令import.ts#L390-L448收尾提醒源码与目标目录不同时会提示更新main/tsConfig/outputPath等相对路径并提醒根目录dependencies/devDependencies不会被导入import.ts#L450-L473。历史保留有一个硬性前提非交互模式下命令会明确打印import.ts#L123-L136Git history will be preserved during this process as long as you MERGE these changes.Do NOT squash and do NOT rebasethe changes when merging branches.若要撤销导入运行git reset HEAD~1 --hard。Agent 模式与 ndjson 输出nx 22.6.0importHandler通过isAiAgent()判断是否运行在 AI Agent 环境中import.ts#L86-L114。Agent 模式下行为有三点不同强制非交互interactive被置为false且--ref、--destination成为必填项缺失时一次性上报并退出结构化 ndjson 输出进度阶段starting → cloning → filtering → merging → detecting-plugins → installing → complete/error/needs_input以及needs_input缺参、待选插件与success含 warnings 列表等结构化消息类型定义见 ai-output.ts#L20-L123。这正是技能文档所说nx import 以 .ndjson 输出并追问后续问题的来源两步式插件流程第一步只完成代码合并、报告检测到的插件needs_inputinputType: plugins第二步在目标目录非空时携带--plugins再运行进入handlePluginOnlyMode只装插件import.ts#L564-L632。错误处理同样结构化错误码枚举覆盖UNCOMMITTED_CHANGES、CLONE_FAILED、SOURCE_NOT_FOUND、DESTINATION_NOT_EMPTY、MERGE_FAILED、PACKAGE_INSTALL_ERROR等ai-output.ts#L33-L44并在 command-object.ts#L61-L80 中捕获后写入错误日志。两种导入策略的选择这是迁移决策中最重要的一环两种模式的取舍如下。子目录逐个导入推荐用于 monorepo 源nx import source apps --sourceapps推荐用于 monorepo 源文件落在目标工作区顶层不会引入冗余配置注意事项多个项目需要多次nx import命令每次产生独立的 merge commit目标不能存在冲突目录源仓库根部的配置dependencies、plugins、targetDefaults不会被导入目录冲突处理先导入到另一个名字的目录例如imported-apps/导入完成后再重命名。整仓导入仅限非 monorepo 源nx import source imported --source.只适用于单项目仓库对 monorepo 源使用会创建混乱的嵌套配置imported/nx.json、imported/tsconfig.base.json等若必须整仓导入保留导入进来的tsconfig.base.json导入的项目可能extends它并给工作区级 glob 与 executor 路径加导入目录前缀。目录约定与项目类型判定始终优先沿用目标工作区的既有约定源用libs/而目标用packages/那就导入到packages/nx import source packages/foo --sourcelibs/foo若目标为空工作区、没有既定约定应与用户确认后再定。导入前还要识别源项目是应用还是库判定依据来自 SKILL.md 的检测规则应用的常见指标前端next.config.*、带构建入口的vite.config.*、框架脚手架CRA、Angular CLI app 等Node.js 后端Express/Fastify/NestJS 服务入口、package.json无exports字段JVMMavenpom.xml含packagingjar/packaging或war且有main类Gradleapplication插件或mainClass配置.NET.csproj/.fsproj含OutputTypeExe/OutputType或WinExe通用Dockerfile、可运行入口、不面向被其他项目导入的公共 API。库的常见指标package.json有main/exports、Maven/Gradle 以库形式打包、.NETOutputTypeLibrary/OutputType、面向其他包导入的具名导出。目标目录规则应用 →apps/name。检查pnpm-workspace.yaml或根package.json的workspaces是否已有apps/*条目若没有先加入该 glob 并提交或暂存再导入。示例nx import source apps/my-app --sourcepackages/my-app库 → 遵循目标工作区既有约定packages/、libs/等。常见问题与修复Nx 源以下问题在技能文档中标注为 Critical 的均按原文完整保留并给出验证入口。pnpm 工作区 glob 写错Criticalnx import向pnpm-workspace.yaml添加的是被导入目录本身如apps而不是其中包的 glob 模式跨包导入会因此报Cannot find module。这与源码中handleMissingWorkspacesEntry直接把relativeDestination写进packages字段的行为一致import.ts#L769-L805。修复改成源配置中的正确 glob如apps/*、libs/shared/*然后pnpm install。根依赖与根配置不导入Criticalnx import不会从源仓库根目录合并package.json的dependencies/devDependenciesnx.json的targetDefaults例如nx/esbuild:esbuild: { dependsOn: [^build] }对构建顺序至关重要nx.json的namedInputs如 test 文件的production排除模式;nx.json的插件配置。源码在导入收尾时会专门打印这条提醒import.ts#L465-L473Agent 模式下则作为missing_root_depswarning 输出import.ts#L519-L525。修复diff 源与目标的package.json与nx.json补齐缺失依赖合并相关targetDefaults与namedInputs。TypeScript 项目引用导入后运行nx sync --yes。若它报告无事可做但 typecheck 仍然失败先nx reset再跑一次nx sync --yes。显式 executor 路径修正插件推断出的 target 相对项目根解析配置无需改动。而显式 executor target如nx/esbuild:esbuild的main、outputPath、tsConfig、assets、sourceRoot是工作区根相对路径必须加上导入目标目录前缀。这也是source ! destination时命令会警告的原因import.ts#L450-L461。插件检测整仓导入nx import会自动检测并提议安装插件接受即可子目录导入插件不会被自动检测需手动npx nx add nx/PLUGIN。注意include/exclude模式——默认值不会匹配换名后的目录如apps-beta/任何插件配置变更后运行npx nx reset。冗余根文件仅整仓导入整仓导入会把源仓库全部根文件带入目标子目录需要清理pnpm-lock.yaml—— 已过时目标有自己的 lockfilepnpm-workspace.yaml—— 源的 workspace 配置与目标冲突node_modules/—— 指向源文件系统的过期软链接.gitignore—— 与目标根目录冗余nx.json—— 源的 Nx 配置目标有自己的README.md—— 可选保留或删除。不要盲目删除tsconfig.base.json——导入进来的项目可能通过相对路径extends它。目标缺少根 ESLint 配置子目录导入子目录导入不会带来源的根eslint.config.mjs但项目级配置引用了../../eslint.config.mjs。修复顺序先装 ESLint 依赖pnpm add -wD eslint^9 nx/eslint-plugin typescript-eslint再加框架相关插件创建根eslint.config.mjs从源复制或用nx/eslint-plugin基础规则新建再npx nx add nx/eslint把插件注册进nx.json。typescript-eslint必须显式安装——pnpm 严格 hoisting 不会自动解析这个nx/eslint-plugin的传递依赖。ESLint 版本锁定Critical把 ESLint 锁定在 v9eslint^9.0.0。ESLint 10 会让nx/eslint和大量插件抛出Cannot read properties of undefined (reading version)之类的晦涩错误。nx/eslint可能 peer-depend 到 ESLint 8导致解析到错误版本。若 lint 报Cannot read properties of undefined (reading allow)在根package.json加pnpm.overrides{ pnpm: { overrides: { eslint: ^9.0.0 } } }依赖版本冲突导入后对比关键依赖typescript、eslint、框架相关包。目标更新则把导入包升级到一致通常安全源更新则可能要先升级目标。可用pnpm.overrides强制单一版本策略。模块边界导入进来的项目可能缺少tags。补上 tags或调整nx/enforce-module-boundaries规则。项目名冲突多次导入源与目标package.json中出现同名name会触发MultipleProjectsWithSameNameError。修复重命名冲突名如org/api→org/teama-api更新所有依赖引用与 import 语句pnpm install。注意每个被导入仓库的根package.json也会成为一个项目需要一并改名。workspace 依赖的导入顺序某个workspace:*依赖对应的项目还没导入时nx import内部的pnpm install会失败文件操作本身仍成功。修复先把所有项目导入完再统一pnpm install --no-frozen-lockfile。.gitkeep阻塞子目录导入TS preset 会创建packages/.gitkeep导致目标目录非空。导入前删掉它并提交。前端 tsconfig 基础设置CriticalTS preset 默认值module: nodenext、moduleResolution: nodenext、lib: [es2022]与前端框架React、Next.js、Vue、Vite不兼容。导入前端项目后检查目标根tsconfig.base.jsonmoduleResolution必须是bundler不能是nodenextmodule必须是esnext不能是nodenextlib必须包含dom与dom.iterable前端项目需要jsx纯 React 工作区用react-jsx混合框架则按项目配置。子目录导入时目标根 tsconfig 是权威配置——改它整仓导入时导入的项目可能 extends 自己的嵌套tsconfig.base.json此问题较轻。若目标同时有依赖nodenext的后端项目用项目级 override而不是改根配置。陷阱TypeScript不合并lib数组——项目级 override 会整体替换基础配置里的数组。任何项目级lib都必须写全所需条目如es2022、dom、dom.iterable。nx/react库的类型声明用nx/react:library生成的 React 库其 tsconfigtypes里引用了nx/react/typings/cssmodule.d.ts与nx/react/typings/image.d.ts目标工作区未安装nx/react时会报Cannot find type definition file。修复pnpm add -wD nx/react。Jest preset 缺失子目录导入Nx preset 在工作区根创建jest.preset.js项目级 jest 配置通过相对路径引用它如../../jest.preset.js而子目录导入不会带过来这个文件。修复npx nx add nx/jest—— 在nx.json注册nx/jest/plugin并更新namedInputs在根目录手工创建jest.preset.js内容见 references/JEST.md——裸跑nx add不会生成它只有跑生成器才会安装测试运行依赖pnpm add -wD jest jest-environment-jsdom ts-jest types/jest按需安装框架测试依赖详见 references/JEST.md。更深的 Jest 问题tsconfig.spec.json、Babel transform、CI 原子化、Jest 与 Vitest 共存参见 references/JEST.md。Target 名称加前缀整仓导入源项目已有 npm scriptsbuild、dev、start、lint时Nx 插件为避免冲突会自动给推断出的 target 名加前缀如next:build、vite:build、eslint:lint。修复删掉被 Nx 改写过的 npm scripts然后二选一——接受带前缀的名字如nx run app:next:build或在nx.json中把插件 target 名改回不带前缀的名字。非 Nx 源的迁移要点当源仓库是没有nx.json的普通 pnpm/npm workspace 时额外注意npm scripts 被改写CriticalNx init 过程会改写package.jsonscripts产生损坏的命令例如vitest run变成nx test run。修复删掉所有被改写的 scripts——Nx 插件会从配置文件推断 target。noEmit→compositeemitDeclarationOnlyCritical普通 TS 项目的noEmit: true与 Nx 项目引用机制不兼容。症状typecheck target 提示 one or more project references set noEmit: true或 TS6310 错误。修复对所有导入的 tsconfig 执行删除noEmit: true若它来自extends链则显式设置noEmit: false加composite: true、emitDeclarationOnly: true、declarationMap: true加outDir: dist与tsBuildInfoFile: dist/tsconfig.tsbuildinfo若缺少extends: ../../tsconfig.base.json则补上并删除现在由 base 继承的设置。过期的 node_modules 与 lockfilenx import可能把源的node_modules/指向源文件系统的 pnpm 软链和pnpm-lock.yaml一起带进来两者都是过期的。修复删除imported/node_modules、imported/pnpm-lock.yaml、imported/pnpm-workspace.yaml、imported/.gitignore然后pnpm install。ESLint 配置处理旧版.eslintrc.jsonESLint 8删除全部.eslintrc.*、移除 v8 依赖、创建 flateslint.config.mjsflat 配置eslint.config.js自包含的配置通常可以原样保留源没有 ESLint从零创建根级与项目级两层配置。TypeScriptpaths别名Nx 依赖package.json的exports pnpm workspace 链接而非 tsconfig 的paths。包若已有正确的exportspaths就是冗余的否则按新目录结构更新paths。按技术栈查阅专项参考识别源仓库的技术栈后对照 references 目录下的专项参考文档执行references/ESLINT.md — ESLint 项目重复的lint/eslint:linttarget、旧版.eslintrc.*lint 生成物、flat 配置.cjs自 lint、typescript-eslintv7/v9 peer 依赖冲突、同一工作区混用 ESLint v8v9references/JEST.md —nx/jest/plugin配置、jest.preset.js、各框架测试依赖、tsconfig.spec.json、Jest 与 Vitest 共存、Babel transform、CI 原子化references/NEXT.md —nx/next/plugintarget、withNx、Next.js TS 配置noEmit、jsx: preserve、用错包管理器自动装依赖、非 Nxcreate-next-app项目导入、Next.jsVite 混合共存references/VITE.md —nx/vite/plugintypecheck target、resolve.alias/__dirname修正、框架依赖、Vue 专项配置、ReactVue 混合共存references/GRADLE.md 与 references/TURBOREPO.md — JVM 生态与 Turborepo 源的迁移指导。收尾清单一次完整的nx import迁移建议按此顺序收尾确认目标是 MERGE 而非 squash/rebase保历史前提→ diff 补齐根package.json与nx.json依赖、targetDefaults、namedInputs→ 修正pnpm-workspace.yamlglob 并pnpm install→nx sync --yes修复项目引用 → 按技术栈参考文档处理 ESLint/Jest/Next/Vite 细节 → 运行npx nx reset后完整跑一遍build、typecheck、test、lint。所有环节若失败源码中的警告与 ndjson 错误码见 ai-output.ts都可以作为定位线索。【免费下载链接】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 nx import 实战指南：将外部仓库与 Git 历史完整迁入 Monorepo
Nx nx import 实战指南将外部仓库与 Git 历史完整迁入 Monorepo【免费下载链接】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 import命令展开讲解如何把外部 Git 仓库或本地目录中的项目连同提交历史一起迁入当前工作区包括子目录导入与整仓导入两种策略的选择、目标目录约定、应用/库识别规则以及 pnpm 工作区 glob、根依赖合并、TypeScript 项目引用、ESLint 版本等十余类高频问题的排查与修复方法。读完后你可以独立完成多仓库 → Nx Monorepo的迁移并具备处理导入后构建、类型检查与测试失败的源码级定位能力。命令核心能力与完整参数nx import的作用是把源仓库或文件夹中的代码带入当前工作区并保留提交历史。命令签名与参数定义在 command-object.tsnx import [sourceRepository] [destinationDirectory]参数类型说明sourceRepository位置参数string源仓库的远程 URL 或本地路径destinationDirectory/--destination位置参数string当前工作区中的目标目录--sourcestring源仓库中要导入的子目录默认整仓--refstring要导入的分支或引用--depthnumber限制 clone 深度加快克隆速度--interactiveboolean交互模式默认true早期版本请始终用--no-interactive并直接指定所有参数--pluginsstring导入后安装的插件skip不装、all装全部检测到的、或逗号分隔列表如nx/vite,nx/jest--verboseboolean输出更详细的错误信息几条来自官方技能文档 SKILL.md 的快速须知运行nx import --help查看可用选项导入前必须保证目标目录为空——例如目标工作区已有libs/utils与libs/models源仓库有libs/ui与libs/data-access时不能把libs/直接整体导入libs/需要逐个导入源库nx22.6.0之后nx import面向 AI Agent 会以.ndjson形式输出进度与追问信息详见下文 Agent 模式一节早期版本则始终以非交互方式运行并直接指定全部 flag。导入流程的源码级拆解importHandler的完整实现位于 import.ts。从源码结构看一次导入实际经历以下步骤理解它对排查导入到一半失败非常关键前置检查目标仓库存在未提交改动时直接抛错——You have uncommitted changes in the destination repositoryimport.ts#L117-L121克隆源仓库到系统临时目录$TMPDIR/nx-import/repo可选--depth限制历史深度import.ts#L176-L193创建临时分支__nx_tmp_import__/ref并检出源分支import.ts#L250-L262历史过滤prepareSourceRepo把源仓库历史改写为源码始终位于目标路径的样子这是 Git 历史得以按目标目录保留的关键import.ts#L286-L293实现见 prepare-source-repo.ts合并进工作区把临时仓库注册为临时 remote 后执行 mergeimport.ts#L295-L311实现见 merge-remote-source.ts补写工作区条目若目标路径未被workspaces/packages覆盖自动把路径写进package.json或pnpm-workspace.yaml并 amend 提交import.ts#L733-L806安装依赖与插件执行安装、detectPlugins检测并安装插件、configurePlugins注册到nx.json每一步失败都不中断导入而是打印手动补救命令import.ts#L390-L448收尾提醒源码与目标目录不同时会提示更新main/tsConfig/outputPath等相对路径并提醒根目录dependencies/devDependencies不会被导入import.ts#L450-L473。历史保留有一个硬性前提非交互模式下命令会明确打印import.ts#L123-L136Git history will be preserved during this process as long as you MERGE these changes.Do NOT squash and do NOT rebasethe changes when merging branches.若要撤销导入运行git reset HEAD~1 --hard。Agent 模式与 ndjson 输出nx 22.6.0importHandler通过isAiAgent()判断是否运行在 AI Agent 环境中import.ts#L86-L114。Agent 模式下行为有三点不同强制非交互interactive被置为false且--ref、--destination成为必填项缺失时一次性上报并退出结构化 ndjson 输出进度阶段starting → cloning → filtering → merging → detecting-plugins → installing → complete/error/needs_input以及needs_input缺参、待选插件与success含 warnings 列表等结构化消息类型定义见 ai-output.ts#L20-L123。这正是技能文档所说nx import 以 .ndjson 输出并追问后续问题的来源两步式插件流程第一步只完成代码合并、报告检测到的插件needs_inputinputType: plugins第二步在目标目录非空时携带--plugins再运行进入handlePluginOnlyMode只装插件import.ts#L564-L632。错误处理同样结构化错误码枚举覆盖UNCOMMITTED_CHANGES、CLONE_FAILED、SOURCE_NOT_FOUND、DESTINATION_NOT_EMPTY、MERGE_FAILED、PACKAGE_INSTALL_ERROR等ai-output.ts#L33-L44并在 command-object.ts#L61-L80 中捕获后写入错误日志。两种导入策略的选择这是迁移决策中最重要的一环两种模式的取舍如下。子目录逐个导入推荐用于 monorepo 源nx import source apps --sourceapps推荐用于 monorepo 源文件落在目标工作区顶层不会引入冗余配置注意事项多个项目需要多次nx import命令每次产生独立的 merge commit目标不能存在冲突目录源仓库根部的配置dependencies、plugins、targetDefaults不会被导入目录冲突处理先导入到另一个名字的目录例如imported-apps/导入完成后再重命名。整仓导入仅限非 monorepo 源nx import source imported --source.只适用于单项目仓库对 monorepo 源使用会创建混乱的嵌套配置imported/nx.json、imported/tsconfig.base.json等若必须整仓导入保留导入进来的tsconfig.base.json导入的项目可能extends它并给工作区级 glob 与 executor 路径加导入目录前缀。目录约定与项目类型判定始终优先沿用目标工作区的既有约定源用libs/而目标用packages/那就导入到packages/nx import source packages/foo --sourcelibs/foo若目标为空工作区、没有既定约定应与用户确认后再定。导入前还要识别源项目是应用还是库判定依据来自 SKILL.md 的检测规则应用的常见指标前端next.config.*、带构建入口的vite.config.*、框架脚手架CRA、Angular CLI app 等Node.js 后端Express/Fastify/NestJS 服务入口、package.json无exports字段JVMMavenpom.xml含packagingjar/packaging或war且有main类Gradleapplication插件或mainClass配置.NET.csproj/.fsproj含OutputTypeExe/OutputType或WinExe通用Dockerfile、可运行入口、不面向被其他项目导入的公共 API。库的常见指标package.json有main/exports、Maven/Gradle 以库形式打包、.NETOutputTypeLibrary/OutputType、面向其他包导入的具名导出。目标目录规则应用 →apps/name。检查pnpm-workspace.yaml或根package.json的workspaces是否已有apps/*条目若没有先加入该 glob 并提交或暂存再导入。示例nx import source apps/my-app --sourcepackages/my-app库 → 遵循目标工作区既有约定packages/、libs/等。常见问题与修复Nx 源以下问题在技能文档中标注为 Critical 的均按原文完整保留并给出验证入口。pnpm 工作区 glob 写错Criticalnx import向pnpm-workspace.yaml添加的是被导入目录本身如apps而不是其中包的 glob 模式跨包导入会因此报Cannot find module。这与源码中handleMissingWorkspacesEntry直接把relativeDestination写进packages字段的行为一致import.ts#L769-L805。修复改成源配置中的正确 glob如apps/*、libs/shared/*然后pnpm install。根依赖与根配置不导入Criticalnx import不会从源仓库根目录合并package.json的dependencies/devDependenciesnx.json的targetDefaults例如nx/esbuild:esbuild: { dependsOn: [^build] }对构建顺序至关重要nx.json的namedInputs如 test 文件的production排除模式;nx.json的插件配置。源码在导入收尾时会专门打印这条提醒import.ts#L465-L473Agent 模式下则作为missing_root_depswarning 输出import.ts#L519-L525。修复diff 源与目标的package.json与nx.json补齐缺失依赖合并相关targetDefaults与namedInputs。TypeScript 项目引用导入后运行nx sync --yes。若它报告无事可做但 typecheck 仍然失败先nx reset再跑一次nx sync --yes。显式 executor 路径修正插件推断出的 target 相对项目根解析配置无需改动。而显式 executor target如nx/esbuild:esbuild的main、outputPath、tsConfig、assets、sourceRoot是工作区根相对路径必须加上导入目标目录前缀。这也是source ! destination时命令会警告的原因import.ts#L450-L461。插件检测整仓导入nx import会自动检测并提议安装插件接受即可子目录导入插件不会被自动检测需手动npx nx add nx/PLUGIN。注意include/exclude模式——默认值不会匹配换名后的目录如apps-beta/任何插件配置变更后运行npx nx reset。冗余根文件仅整仓导入整仓导入会把源仓库全部根文件带入目标子目录需要清理pnpm-lock.yaml—— 已过时目标有自己的 lockfilepnpm-workspace.yaml—— 源的 workspace 配置与目标冲突node_modules/—— 指向源文件系统的过期软链接.gitignore—— 与目标根目录冗余nx.json—— 源的 Nx 配置目标有自己的README.md—— 可选保留或删除。不要盲目删除tsconfig.base.json——导入进来的项目可能通过相对路径extends它。目标缺少根 ESLint 配置子目录导入子目录导入不会带来源的根eslint.config.mjs但项目级配置引用了../../eslint.config.mjs。修复顺序先装 ESLint 依赖pnpm add -wD eslint^9 nx/eslint-plugin typescript-eslint再加框架相关插件创建根eslint.config.mjs从源复制或用nx/eslint-plugin基础规则新建再npx nx add nx/eslint把插件注册进nx.json。typescript-eslint必须显式安装——pnpm 严格 hoisting 不会自动解析这个nx/eslint-plugin的传递依赖。ESLint 版本锁定Critical把 ESLint 锁定在 v9eslint^9.0.0。ESLint 10 会让nx/eslint和大量插件抛出Cannot read properties of undefined (reading version)之类的晦涩错误。nx/eslint可能 peer-depend 到 ESLint 8导致解析到错误版本。若 lint 报Cannot read properties of undefined (reading allow)在根package.json加pnpm.overrides{ pnpm: { overrides: { eslint: ^9.0.0 } } }依赖版本冲突导入后对比关键依赖typescript、eslint、框架相关包。目标更新则把导入包升级到一致通常安全源更新则可能要先升级目标。可用pnpm.overrides强制单一版本策略。模块边界导入进来的项目可能缺少tags。补上 tags或调整nx/enforce-module-boundaries规则。项目名冲突多次导入源与目标package.json中出现同名name会触发MultipleProjectsWithSameNameError。修复重命名冲突名如org/api→org/teama-api更新所有依赖引用与 import 语句pnpm install。注意每个被导入仓库的根package.json也会成为一个项目需要一并改名。workspace 依赖的导入顺序某个workspace:*依赖对应的项目还没导入时nx import内部的pnpm install会失败文件操作本身仍成功。修复先把所有项目导入完再统一pnpm install --no-frozen-lockfile。.gitkeep阻塞子目录导入TS preset 会创建packages/.gitkeep导致目标目录非空。导入前删掉它并提交。前端 tsconfig 基础设置CriticalTS preset 默认值module: nodenext、moduleResolution: nodenext、lib: [es2022]与前端框架React、Next.js、Vue、Vite不兼容。导入前端项目后检查目标根tsconfig.base.jsonmoduleResolution必须是bundler不能是nodenextmodule必须是esnext不能是nodenextlib必须包含dom与dom.iterable前端项目需要jsx纯 React 工作区用react-jsx混合框架则按项目配置。子目录导入时目标根 tsconfig 是权威配置——改它整仓导入时导入的项目可能 extends 自己的嵌套tsconfig.base.json此问题较轻。若目标同时有依赖nodenext的后端项目用项目级 override而不是改根配置。陷阱TypeScript不合并lib数组——项目级 override 会整体替换基础配置里的数组。任何项目级lib都必须写全所需条目如es2022、dom、dom.iterable。nx/react库的类型声明用nx/react:library生成的 React 库其 tsconfigtypes里引用了nx/react/typings/cssmodule.d.ts与nx/react/typings/image.d.ts目标工作区未安装nx/react时会报Cannot find type definition file。修复pnpm add -wD nx/react。Jest preset 缺失子目录导入Nx preset 在工作区根创建jest.preset.js项目级 jest 配置通过相对路径引用它如../../jest.preset.js而子目录导入不会带过来这个文件。修复npx nx add nx/jest—— 在nx.json注册nx/jest/plugin并更新namedInputs在根目录手工创建jest.preset.js内容见 references/JEST.md——裸跑nx add不会生成它只有跑生成器才会安装测试运行依赖pnpm add -wD jest jest-environment-jsdom ts-jest types/jest按需安装框架测试依赖详见 references/JEST.md。更深的 Jest 问题tsconfig.spec.json、Babel transform、CI 原子化、Jest 与 Vitest 共存参见 references/JEST.md。Target 名称加前缀整仓导入源项目已有 npm scriptsbuild、dev、start、lint时Nx 插件为避免冲突会自动给推断出的 target 名加前缀如next:build、vite:build、eslint:lint。修复删掉被 Nx 改写过的 npm scripts然后二选一——接受带前缀的名字如nx run app:next:build或在nx.json中把插件 target 名改回不带前缀的名字。非 Nx 源的迁移要点当源仓库是没有nx.json的普通 pnpm/npm workspace 时额外注意npm scripts 被改写CriticalNx init 过程会改写package.jsonscripts产生损坏的命令例如vitest run变成nx test run。修复删掉所有被改写的 scripts——Nx 插件会从配置文件推断 target。noEmit→compositeemitDeclarationOnlyCritical普通 TS 项目的noEmit: true与 Nx 项目引用机制不兼容。症状typecheck target 提示 one or more project references set noEmit: true或 TS6310 错误。修复对所有导入的 tsconfig 执行删除noEmit: true若它来自extends链则显式设置noEmit: false加composite: true、emitDeclarationOnly: true、declarationMap: true加outDir: dist与tsBuildInfoFile: dist/tsconfig.tsbuildinfo若缺少extends: ../../tsconfig.base.json则补上并删除现在由 base 继承的设置。过期的 node_modules 与 lockfilenx import可能把源的node_modules/指向源文件系统的 pnpm 软链和pnpm-lock.yaml一起带进来两者都是过期的。修复删除imported/node_modules、imported/pnpm-lock.yaml、imported/pnpm-workspace.yaml、imported/.gitignore然后pnpm install。ESLint 配置处理旧版.eslintrc.jsonESLint 8删除全部.eslintrc.*、移除 v8 依赖、创建 flateslint.config.mjsflat 配置eslint.config.js自包含的配置通常可以原样保留源没有 ESLint从零创建根级与项目级两层配置。TypeScriptpaths别名Nx 依赖package.json的exports pnpm workspace 链接而非 tsconfig 的paths。包若已有正确的exportspaths就是冗余的否则按新目录结构更新paths。按技术栈查阅专项参考识别源仓库的技术栈后对照 references 目录下的专项参考文档执行references/ESLINT.md — ESLint 项目重复的lint/eslint:linttarget、旧版.eslintrc.*lint 生成物、flat 配置.cjs自 lint、typescript-eslintv7/v9 peer 依赖冲突、同一工作区混用 ESLint v8v9references/JEST.md —nx/jest/plugin配置、jest.preset.js、各框架测试依赖、tsconfig.spec.json、Jest 与 Vitest 共存、Babel transform、CI 原子化references/NEXT.md —nx/next/plugintarget、withNx、Next.js TS 配置noEmit、jsx: preserve、用错包管理器自动装依赖、非 Nxcreate-next-app项目导入、Next.jsVite 混合共存references/VITE.md —nx/vite/plugintypecheck target、resolve.alias/__dirname修正、框架依赖、Vue 专项配置、ReactVue 混合共存references/GRADLE.md 与 references/TURBOREPO.md — JVM 生态与 Turborepo 源的迁移指导。收尾清单一次完整的nx import迁移建议按此顺序收尾确认目标是 MERGE 而非 squash/rebase保历史前提→ diff 补齐根package.json与nx.json依赖、targetDefaults、namedInputs→ 修正pnpm-workspace.yamlglob 并pnpm install→nx sync --yes修复项目引用 → 按技术栈参考文档处理 ESLint/Jest/Next/Vite 细节 → 运行npx nx reset后完整跑一遍build、typecheck、test、lint。所有环节若失败源码中的警告与 ndjson 错误码见 ai-output.ts都可以作为定位线索。【免费下载链接】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），仅供参考