nx-import

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

name: nx-import description: Import, merge, or combine repositories into an Nx workspace using nx import. USE WHEN the user asks to adopt Nx across repos, move projects into a monorepo, or bring code/history from another repository.

name: nx-import description: 使用nx import将代码仓库导入、合并或整合到Nx工作区中。适用于用户需要在多仓库中采用Nx、将项目迁移到单体仓库（monorepo），或从其他仓库引入代码/提交历史的场景。

Quick Start

快速开始

```
nx import
```
brings code from a source repository or folder into the current workspace, preserving commit history.
After nx
```
22.6.0
```
,
```
nx import
```
responds with .ndjson outputs and follow-up questions. For earlier versions, always run with
```
--no-interactive
```
and specify all flags directly.
Run
```
nx import --help
```
for available options.
Make sure the destination directory is empty before importing. EXAMPLE: target has
```
libs/utils
```
and
```
libs/models
```
; source has
```
libs/ui
```
and
```
libs/data-access
```
— you cannot import
```
libs/
```
into
```
libs/
```
directly. Import each source library individually.

Primary docs:

Read the nx docs if you have the tools for it.

```
nx import
```
可将源仓库或文件夹中的代码引入当前工作区，同时保留提交历史。
在Nx 22.6.0版本之后，
```
nx import
```
会返回.ndjson格式的输出并提出后续问题。对于更早的版本，请始终使用
```
--no-interactive
```
参数运行，并直接指定所有必要的标志。
运行
```
nx import --help
```
查看可用选项。
导入前请确保目标目录为空。示例：目标目录包含
```
libs/utils
```
和
```
libs/models
```
；源目录包含
```
libs/ui
```
和
```
libs/data-access
```
——不能直接将
```
libs/
```
导入到
```
libs/
```
中。请分别导入每个源库。

主要文档：

如果有条件，请阅读Nx官方文档。

Import Strategy

导入策略

Subdirectory-at-a-time (

nx import <source> apps --source=apps

Recommended for monorepo sources — files land at top level, no redundant config
Caveats: multiple import commands (separate merge commits each); dest must not have conflicting directories; root configs (deps, plugins, targetDefaults) not imported
Directory conflicts: Import into alternate-named dir (e.g.
```
imported-apps/
```
), then rename

Whole repo (

nx import <source> imported --source=.

Only for non-monorepo sources (single-project repos)
For monorepos, creates messy nested config (
```
imported/nx.json
```
,
```
imported/tsconfig.base.json
```
, etc.)
If you must: keep imported
```
tsconfig.base.json
```
(projects extend it), prefix workspace globs and executor paths

逐个子目录导入（

nx import <source> apps --source=apps

）：

推荐用于单体仓库源——文件将直接放在顶层目录，无冗余配置
注意事项：需要执行多次导入命令（每次导入对应单独的合并提交）；目标目录不能存在冲突的目录；不会导入根目录配置（依赖、插件、targetDefaults）
目录冲突处理：导入到重命名后的目录（例如
```
imported-apps/
```
），之后再进行重命名

整个仓库导入（

nx import <source> imported --source=.

）：

仅适用于非单体仓库源（单项目仓库）
若用于单体仓库，会产生混乱的嵌套配置（
```
imported/nx.json
```
、
```
imported/tsconfig.base.json
```
等）
若必须使用：保留导入的
```
tsconfig.base.json
```
（项目会继承该配置），为工作区通配符和执行器路径添加前缀

Directory Conventions

目录约定

Always prefer the destination's existing conventions. Source uses
```
libs/
```
but dest uses
```
packages/
```
? Import into
```
packages/
```
(
```
nx import <source> packages/foo --source=libs/foo
```
).
If dest has no convention (empty workspace), ask the user.

始终优先遵循目标目录的现有约定。如果源目录使用
```
libs/
```
而目标目录使用
```
packages/
```
？请导入到
```
packages/
```
（
```
nx import <source> packages/foo --source=libs/foo
```
）。
如果目标目录没有约定（空工作区），请询问用户。

Common Issues

常见问题

pnpm Workspace Globs (Critical)

pnpm工作区通配符（关键）

nx import

adds the imported directory itself (e.g.

apps

) to

pnpm-workspace.yaml

, NOT glob patterns for packages within it. Cross-package imports will fail with

Cannot find module

Fix: Replace with proper globs from the source config (e.g.

apps/*

libs/shared/*

), then

pnpm install

nx import

会将导入的目录本身（例如

apps

）添加到

pnpm-workspace.yaml

中，而非目录内包的通配符模式。跨包导入会出现

Cannot find module

错误。

修复方法：使用源配置中的正确通配符替换（例如

apps/*

、

libs/shared/*

），然后执行

pnpm install

。

Root Dependencies and Config Not Imported (Critical)

根目录依赖与配置未导入（关键）

nx import

does NOT merge from the source's root:

```
dependencies
```
/
```
devDependencies
```
from
```
package.json
```

targetDefaults

from

nx.json

(e.g.

"@nx/esbuild:esbuild": { "dependsOn": ["^build"] }

— critical for build ordering)

```
namedInputs
```
from
```
nx.json
```
(e.g.
```
production
```
exclusion patterns for test files)
Plugin configurations from
```
nx.json
```

Fix: Diff source and dest

package.json

nx.json

. Add missing deps, merge relevant

targetDefaults

and

namedInputs

nx import

不会合并源仓库根目录的以下内容：

```
package.json
```
中的
```
dependencies
```
/
```
devDependencies
```

nx.json

中的

targetDefaults

（例如

"@nx/esbuild:esbuild": { "dependsOn": ["^build"] }

——对构建顺序至关重要）

```
nx.json
```
中的
```
namedInputs
```
（例如用于排除测试文件的
```
production
```
模式）
```
nx.json
```
中的插件配置

修复方法：对比源和目标的

package.json

nx.json

。添加缺失的依赖，合并相关的

targetDefaults

和

namedInputs

。

TypeScript Project References

TypeScript项目引用

After import, run

nx sync --yes

. If it reports nothing but typecheck still fails,

nx reset

first, then

nx sync --yes

again.

导入完成后，执行

nx sync --yes

。如果命令无输出但类型检查仍失败，请先执行

nx reset

，再重新运行

nx sync --yes

。

Explicit Executor Path Fixups

显式执行器路径修正

Inferred targets (via Nx plugins) resolve config relative to project root — no changes needed. Explicit executor targets (e.g.

@nx/esbuild:esbuild

) have workspace-root-relative paths (

main

outputPath

tsConfig

assets

sourceRoot

) that must be prefixed with the import destination directory.

通过Nx插件推断的目标会相对于项目根目录解析配置——无需修改。显式执行器目标（例如

@nx/esbuild:esbuild

）的路径（

main

、

outputPath

、

tsConfig

、

assets

、

sourceRoot

）是相对于工作区根目录的，需要为其添加导入目标目录的前缀。

Plugin Detection

插件检测

Whole-repo import:
```
nx import
```
detects and offers to install plugins. Accept them.
Subdirectory import: Plugins NOT auto-detected. Manually add with
```
npx nx add @nx/PLUGIN
```
. Check
```
include
```
/
```
exclude
```
patterns — defaults won't match alternate directories (e.g.
```
apps-beta/
```
).
Run
```
npx nx reset
```
after any plugin config changes.

整个仓库导入：
```
nx import
```
会自动检测并提示安装插件。请确认安装。
子目录导入：不会自动检测插件。请手动通过
```
npx nx add @nx/PLUGIN
```
添加。检查
```
include
```
/
```
exclude
```
模式——默认配置可能不匹配自定义目录（例如
```
apps-beta/
```
）。
任何插件配置变更后，请执行
```
npx nx reset
```
。

Redundant Root Files (Whole-Repo Only)

冗余根目录文件（仅整个仓库导入）

Whole-repo import brings ALL source root files into the dest subdirectory. Clean up:

```
pnpm-lock.yaml
```
— stale; dest has its own lockfile
```
pnpm-workspace.yaml
```
— source workspace config; conflicts with dest
```
node_modules/
```
— stale symlinks pointing to source filesystem
```
.gitignore
```
— redundant with dest root
```
.gitignore
```
```
nx.json
```
— source Nx config; dest has its own
```
README.md
```
— optional; keep or remove

Don't blindly delete

tsconfig.base.json

— imported projects may extend it via relative paths.

整个仓库导入会将源仓库的所有根目录文件带入目标子目录。请清理以下文件：

```
pnpm-lock.yaml
```
——已过期；目标仓库已有自己的锁文件
```
pnpm-workspace.yaml
```
——源仓库的工作区配置；与目标仓库冲突
```
node_modules/
```
——已过期的软链接，指向源文件系统
```
.gitignore
```
——与目标仓库根目录的
```
.gitignore
```
重复
```
nx.json
```
——源仓库的Nx配置；目标仓库已有自己的配置
```
README.md
```
——可选；可保留或删除

请勿盲目删除

tsconfig.base.json

——导入的项目可能通过相对路径继承该配置。

Root ESLint Config Missing (Subdirectory Import)

Subdirectory import doesn't bring the source's root

eslint.config.mjs

, but project configs reference

../../eslint.config.mjs

Fix order:

Install ESLint deps first:
```
pnpm add -wD eslint@^9 @nx/eslint-plugin typescript-eslint
```
(plus framework-specific plugins)
Create root
```
eslint.config.mjs
```
(copy from source or create with
```
@nx/eslint-plugin
```
base rules)
Then
```
npx nx add @nx/eslint
```
to register the plugin in
```
nx.json
```

Install

typescript-eslint

explicitly — pnpm's strict hoisting won't auto-resolve this transitive dep of

@nx/eslint-plugin

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的严格提升规则不会自动解析

@nx/eslint-plugin

的这个传递依赖。

ESLint Version Pinning (Critical)

ESLint版本锁定（关键）

Pin ESLint to v9 (

eslint@^9.0.0

). ESLint 10 breaks

@nx/eslint

and many plugins with cryptic errors like

Cannot read properties of undefined (reading 'version')

@nx/eslint

may peer-depend on ESLint 8, causing the wrong version to resolve. If lint fails with

Cannot read properties of undefined (reading 'allow')

, add

pnpm.overrides

json

{ "pnpm": { "overrides": { "eslint": "^9.0.0" } } }

请将ESLint锁定为v9版本（

eslint@^9.0.0

）。ESLint 10会导致

@nx/eslint

及许多插件崩溃，出现类似

Cannot read properties of undefined (reading 'version')

的模糊错误。

@nx/eslint

的对等依赖可能指定ESLint 8，导致解析到错误版本。如果 lint 失败并提示

Cannot read properties of undefined (reading 'allow')

，请添加

pnpm.overrides

：

json

{ "pnpm": { "overrides": { "eslint": "^9.0.0" } } }

Dependency Version Conflicts

依赖版本冲突

After import, compare key deps (

typescript

eslint

, framework-specific). If dest uses newer versions, upgrade imported packages to match (usually safe). If source is newer, may need to upgrade dest first. Use

pnpm.overrides

to enforce single-version policy if desired.

导入完成后，对比关键依赖版本（

typescript

、

eslint

、框架特定依赖）。如果目标仓库使用较新版本，可升级导入的包以匹配（通常是安全的）。如果源仓库版本更新，可能需要先升级目标仓库。若需要，可使用

pnpm.overrides

强制统一版本。

Module Boundaries

模块边界

Imported projects may lack

tags

. Add tags or update

@nx/enforce-module-boundaries

rules.

导入的项目可能缺少

tags

。请添加标签或更新

@nx/enforce-module-boundaries

规则。

Project Name Collisions (Multi-Import)

项目名称冲突（多仓库导入）

Same

name

package.json

across source and dest causes

MultipleProjectsWithSameNameError

. Fix: Rename conflicting names (e.g.

@org/api

→

@org/teama-api

), update all dep references and import statements,

pnpm install

. The root

package.json

of each imported repo also becomes a project — rename those too.

源仓库与目标仓库的

package.json

中存在相同的

name

会导致

MultipleProjectsWithSameNameError

。修复方法：重命名冲突的名称（例如

@org/api

→

@org/teama-api

），更新所有依赖引用和导入语句，执行

pnpm install

。每个导入仓库的根目录

package.json

也会成为一个项目——请一并重命名。

Workspace Dep Import Ordering

工作区依赖导入顺序

pnpm install

fails during

nx import

if a

"workspace:*"

dependency hasn't been imported yet. File operations still succeed. Fix: Import all projects first, then

pnpm install --no-frozen-lockfile

如果

"workspace:*"

依赖尚未导入，

nx import

过程中执行

pnpm install

会失败，但文件操作仍会成功。修复方法：先导入所有项目，再执行

pnpm install --no-frozen-lockfile

。

.gitkeep

Blocking Subdirectory Import

.gitkeep

阻止子目录导入

The TS preset creates

packages/.gitkeep

. Remove it and commit before importing.

TS预设会创建

packages/.gitkeep

。请删除该文件并提交后再进行导入。

Frontend tsconfig Base Settings (Critical)

前端tsconfig基础设置（关键）

The TS preset defaults (

module: "nodenext"

moduleResolution: "nodenext"

lib: ["es2022"]

) are incompatible with frontend frameworks (React, Next.js, Vue, Vite). After importing frontend projects, verify the dest root

tsconfig.base.json

moduleResolution
: Must be
```
"bundler"
```
(not
```
"nodenext"
```
)
module
: Must be
```
"esnext"
```
(not
```
"nodenext"
```
)
lib
: Must include
```
"dom"
```
and
```
"dom.iterable"
```
(frontend projects need these)
jsx
:
```
"react-jsx"
```
for React-only workspaces, per-project for mixed frameworks

For subdirectory imports, the dest root tsconfig is authoritative — update it. For whole-repo imports, imported projects may extend their own nested

tsconfig.base.json

, making this less critical.

If the dest also has backend projects needing

nodenext

, use per-project overrides instead of changing the root.

Gotcha: TypeScript does NOT merge

lib

arrays — a project-level override replaces the base array entirely. Always include all needed entries (e.g.

es2022

dom

dom.iterable

) in any project-level

lib

TS预设的默认配置（

module: "nodenext"

、

moduleResolution: "nodenext"

、

lib: ["es2022"]

）与前端框架（React、Next.js、Vue、Vite）不兼容。导入前端项目后，请验证目标仓库根目录的

tsconfig.base.json

：

moduleResolution
：必须设置为
```
"bundler"
```
（不能是
```
"nodenext"
```
）
module
：必须设置为
```
"esnext"
```
（不能是
```
"nodenext"
```
）
lib
：必须包含
```
"dom"
```
和
```
"dom.iterable"
```
（前端项目需要这些）
jsx
：纯React工作区设置为
```
"react-jsx"
```
，混合框架工作区可按项目单独配置

对于子目录导入，目标仓库根目录的tsconfig是权威配置——请更新它。对于整个仓库导入，导入的项目可能继承自己嵌套的

tsconfig.base.json

，因此这一点不太关键。

如果目标仓库同时有需要

nodenext

配置的后端项目，请使用项目级别的覆盖配置，而非修改根目录配置。

注意：TypeScript不会合并

lib

数组——项目级别的覆盖配置会完全替换基础数组。请确保项目级

lib

数组包含所有必要的条目（例如

es2022

、

dom

、

dom.iterable

）。

@nx/react

Typings for Libraries

@nx/react

库类型定义

React libraries generated with

@nx/react:library

reference

@nx/react/typings/cssmodule.d.ts

and

@nx/react/typings/image.d.ts

in their tsconfig

types

. These fail with

Cannot find type definition file

unless

@nx/react

is installed in the dest workspace.

Fix:

pnpm add -wD @nx/react

使用

@nx/react:library

生成的React库会在其tsconfig的

types

中引用

@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 Missing (Subdirectory Import)

Jest预设缺失（子目录导入）

Nx presets create

jest.preset.js

at the workspace root, and project jest configs reference it (e.g.

../../jest.preset.js

). Subdirectory import does NOT bring this file.

Fix:

Run

npx nx add @nx/jest

— registers

@nx/jest/plugin

nx.json

and updates

namedInputs

Create
```
jest.preset.js
```
at workspace root (see
```
references/JEST.md
```
for content) —
```
nx add
```
only creates this when a generator runs, not on bare
```
nx add
```

Install test runner deps:

pnpm add -wD jest jest-environment-jsdom ts-jest @types/jest

Install framework-specific test deps as needed (see
```
references/JEST.md
```
)

For deeper Jest issues (tsconfig.spec.json, Babel transforms, CI atomization, Jest vs Vitest coexistence), see

references/JEST.md

Nx预设会在工作区根目录创建

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
```
仅在生成器运行时创建该文件，裸
```
nx add
```
不会创建

安装测试运行器依赖：

pnpm add -wD jest jest-environment-jsdom ts-jest @types/jest

按需安装框架特定测试依赖（参考
```
references/JEST.md
```
）

若遇到更复杂的Jest问题（tsconfig.spec.json、Babel转换、CI原子化、Jest与Vite共存），请查看

references/JEST.md

。

Target Name Prefixing (Whole-Repo Import)

目标名称前缀（整个仓库导入）

When importing a project with existing npm scripts (

build

dev

start

lint

), Nx plugins auto-prefix inferred target names to avoid conflicts: e.g.

next:build

vite:build

eslint:lint

Fix: Remove the Nx-rewritten npm scripts from the imported

package.json

, then either:

Accept the prefixed names (e.g.
```
nx run app:next:build
```
)
Rename plugin target names in
```
nx.json
```
to use unprefixed names

当导入的项目已有npm脚本（

build

、

dev

、

start

、

lint

）时，Nx插件会自动为推断的目标名称添加前缀以避免冲突：例如

next:build

、

vite:build

、

eslint:lint

。

修复方法：从导入的

package.json

中删除Nx重写的npm脚本，然后选择以下方式之一：

接受带前缀的名称（例如
```
nx run app:next:build
```
）
在
```
nx.json
```
中重命名插件目标名称，使用无前缀的名称

Non-Nx Source Issues

非Nx源仓库问题

When the source is a plain pnpm/npm workspace without

nx.json

当源仓库是没有

nx.json

的普通pnpm/npm工作区时。

npm Script Rewriting (Critical)

npm脚本重写（关键）

Nx rewrites

package.json

scripts during init, creating broken commands (e.g.

vitest run

→

nx test run

). Fix: Remove all rewritten scripts — Nx plugins infer targets from config files.

Nx在初始化过程中会重写

package.json

中的脚本，生成无效命令（例如

vitest run

→

nx test run

）。修复方法：删除所有被重写的脚本——Nx插件会从配置文件中推断目标。

noEmit

→

composite

emitDeclarationOnly

(Critical)

noEmit

→

composite

emitDeclarationOnly

（关键）

Plain TS projects use

"noEmit": true

, incompatible with Nx project references.

Symptoms: "typecheck target is disabled because one or more project references set 'noEmit: true'" or TS6310.

Fix in all imported tsconfigs:

Remove
```
"noEmit": true
```
. If inherited via extends chain, set
```
"noEmit": false
```
explicitly.

Add

"composite": true

"emitDeclarationOnly": true

"declarationMap": true

Add

"outDir": "dist"

and

"tsBuildInfoFile": "dist/tsconfig.tsbuildinfo"

Add
```
"extends": "../../tsconfig.base.json"
```
if missing. Remove settings now inherited from base.

普通TS项目使用

"noEmit": true

，与Nx项目引用不兼容。

症状："typecheck目标已禁用，因为一个或多个项目引用设置了'noEmit: true'" 或 TS6310错误。

修复方法（所有导入的tsconfig文件）：

删除
```
"noEmit": true
```
。如果是通过继承链获得的该配置，请显式设置
```
"noEmit": false
```
。

添加

"composite": true

、

"emitDeclarationOnly": true

、

"declarationMap": true

添加

"outDir": "dist"

和

"tsBuildInfoFile": "dist/tsconfig.tsbuildinfo"

若缺失，请添加
```
"extends": "../../tsconfig.base.json"
```
。删除现在从基础配置继承的设置。

Stale node_modules and Lockfiles

过期的node_modules与锁文件

nx import

may bring

node_modules/

(pnpm symlinks pointing to the source filesystem) and

pnpm-lock.yaml

from the source. Both are stale.

Fix:

rm -rf imported/node_modules imported/pnpm-lock.yaml imported/pnpm-workspace.yaml imported/.gitignore

, then

pnpm install

nx import

可能会带入源仓库的

node_modules/

（指向源文件系统的pnpm软链接）和

pnpm-lock.yaml

。两者均已过期。

修复方法：执行

rm -rf imported/node_modules imported/pnpm-lock.yaml imported/pnpm-workspace.yaml imported/.gitignore

，然后执行

pnpm install

。

ESLint Config Handling

ESLint配置处理

Legacy
.eslintrc.json
(ESLint 8): Delete all
```
.eslintrc.*
```
, remove v8 deps, create flat
```
eslint.config.mjs
```
.
Flat config (
eslint.config.js
): Self-contained configs can often be left as-is.
No ESLint: Create both root and project-level configs from scratch.

传统
.eslintrc.json
（ESLint 8）：删除所有
```
.eslintrc.*
```
文件，移除v8版本依赖，创建扁平配置
```
eslint.config.mjs
```
。
扁平配置（
eslint.config.js
）：独立的配置通常可直接保留。
无ESLint配置：从头创建根目录和项目级别的配置。

TypeScript

paths

Aliases

TypeScript

paths

别名

Nx uses

package.json

"exports"

+ pnpm workspace linking instead of tsconfig

"paths"

. If packages have proper

"exports"

, paths are redundant. Otherwise, update paths for the new directory structure.

Nx使用

package.json

的

"exports"

+ pnpm工作区链接，而非tsconfig的

"paths"

。如果包有正确的

"exports"

配置，

paths

是冗余的。否则，请根据新的目录结构更新

paths

。

Technology-specific Guidance

技术特定指南

Identify technologies in the source repo, then read and apply the matching reference file(s).

Available references:

```
references/GRADLE.md
```
```
references/JEST.md
```
— Jest testing:
```
@nx/jest/plugin
```
setup, jest.preset.js, testing deps by framework, tsconfig.spec.json, Jest vs Vitest coexistence, Babel transforms, CI atomization.
```
references/NEXT.md
```
— Next.js projects:
```
@nx/next/plugin
```
targets,
```
withNx
```
, Next.js TS config (
```
noEmit
```
,
```
jsx: "preserve"
```
), auto-installing deps via wrong PM, non-Nx
```
create-next-app
```
imports, mixed Next.js+Vite coexistence.
```
references/TURBOREPO.md
```
```
references/VITE.md
```
— Vite projects (React, Vue, or both):
```
@nx/vite/plugin
```
typecheck target,
```
resolve.alias
```
/
```
__dirname
```
fixes, framework deps, Vue-specific setup, mixed React+Vue coexistence.

识别源仓库中的技术栈，然后阅读并应用对应的参考文档。

可用参考文档：

```
references/GRADLE.md
```
```
references/JEST.md
```
— Jest测试：
```
@nx/jest/plugin
```
配置、jest.preset.js、各框架测试依赖、tsconfig.spec.json、Jest与Vitest共存、Babel转换、CI原子化。
```
references/NEXT.md
```
— Next.js项目：
```
@nx/next/plugin
```
目标、
```
withNx
```
、Next.js TS配置（
```
noEmit
```
、
```
jsx: "preserve"
```
）、错误包管理器自动安装依赖、非Nx
```
create-next-app
```
导入、Next.js+Vite混合共存。
```
references/TURBOREPO.md
```
```
references/VITE.md
```
— Vite项目（React、Vue或两者混合）：
```
@nx/vite/plugin
```
类型检查目标、
```
resolve.alias
```
/
```
__dirname
```
修复、框架依赖、Vue特定配置、React+Vue混合共存。

nx-import

Original

Translation

Quick Start

快速开始

Import Strategy

导入策略

Directory Conventions

目录约定

Common Issues

常见问题

pnpm Workspace Globs (Critical)

pnpm工作区通配符（关键）

Root Dependencies and Config Not Imported (Critical)

根目录依赖与配置未导入（关键）

TypeScript Project References

TypeScript项目引用

Explicit Executor Path Fixups

显式执行器路径修正

Plugin Detection

插件检测

Redundant Root Files (Whole-Repo Only)

冗余根目录文件（仅整个仓库导入）

Root ESLint Config Missing (Subdirectory Import)

根目录ESLint配置缺失（子目录导入）

ESLint Version Pinning (Critical)

ESLint版本锁定（关键）

Dependency Version Conflicts

依赖版本冲突

Module Boundaries

模块边界

Project Name Collisions (Multi-Import)

项目名称冲突（多仓库导入）

Workspace Dep Import Ordering

工作区依赖导入顺序

.gitkeep Blocking Subdirectory Import

.gitkeep阻止子目录导入

Frontend tsconfig Base Settings (Critical)

前端tsconfig基础设置（关键）

@nx/react Typings for Libraries

@nx/react库类型定义

Jest Preset Missing (Subdirectory Import)

Jest预设缺失（子目录导入）

Target Name Prefixing (Whole-Repo Import)

目标名称前缀（整个仓库导入）

Non-Nx Source Issues

非Nx源仓库问题

npm Script Rewriting (Critical)

npm脚本重写（关键）

noEmit → composite + emitDeclarationOnly (Critical)

noEmit → composite + emitDeclarationOnly（关键）

Stale node_modules and Lockfiles

过期的node_modules与锁文件

ESLint Config Handling

ESLint配置处理

TypeScript paths Aliases

TypeScript paths别名

Technology-specific Guidance

技术特定指南

`.gitkeep`
Blocking Subdirectory Import

`.gitkeep`
阻止子目录导入

`@nx/react`
Typings for Libraries

`@nx/react`
库类型定义

`noEmit`
→
`composite`
+
`emitDeclarationOnly`
(Critical)

`noEmit`
→
`composite`
+
`emitDeclarationOnly`
（关键）

TypeScript
`paths`
Aliases

TypeScript
`paths`
别名