Nx工作区跨库导入出现TS6059错误，修改rootDir是否为最佳实践？

我完全理解你的顾虑——修改每个库的rootDir确实感觉像是在用“偏方”，而且完全违背了Nx设计的库隔离原则，这个方案绝对不是Nx场景下的最佳实践，甚至会破坏Nx工作区的核心特性。

Nx本身原生支持跨库导入，根本不需要这种 workaround。你遇到的TS6059错误，本质是配置不符合Nx的工作区约定，而非Nx需要依赖这种不优雅的修改。下面是正确的、符合Nx规范的解决方法：

1. 先纠正导入方式：用Nx的别名导入而非相对路径 #

你遇到这个错误的常见原因之一是使用了相对路径直接导入库文件，比如：

import { myFunction } from '../../lib1/lib1.ts'

这会让TypeScript认为你在跨rootDir引用文件，触发TS6059。

Nx的正确做法是使用工作区别名导入，每个库在project.json里都有一个name字段（比如@my-workspace/lib1），你应该这样导入：

import { myFunction } from '@my-workspace/lib1'

这种方式会通过工作区根目录的tsconfig.base.json的路径映射，让TypeScript正确识别库的入口，同时保持每个库的rootDir独立。

2. 检查并修复工作区的TypeScript配置 #

Nx的默认生成器会自动配置好所有必要的TS规则，如果你手动修改过配置或者创建了库，可能需要检查以下几点：

（1）工作根目录的tsconfig.base.json

这个文件是整个工作区的TS基础配置，所有库的TS配置都应该继承它。确保compilerOptions里的paths包含了所有库的正确映射，比如：

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@my-workspace/lib1": ["libs/lib1/src/index.ts"],
      "@my-workspace/lib2": ["libs/lib2/src/index.ts"]
    }
  }
}

Nx的lib生成器会自动添加这些条目，如果你手动创建了库，需要手动补充。

（2）单个库的tsconfig.lib.json和tsconfig.json

每个库的TS配置应该保持rootDir为当前库的源码目录（默认是./src），绝对不要改成上级目录。比如lib1的tsconfig.lib.json应该是：

{
  "extends": "../../tsconfig.base.json",
  "compilerOptions": {
    "rootDir": "./src",
    "outDir": "../../dist/libs/lib1"
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "dist", "**/*.spec.ts"]
}

这个配置确保TypeScript只处理当前库的源码，同时通过继承tsconfig.base.json获取工作区的别名映射。

3. 确保Nx正确识别库之间的依赖关系 #

当你在一个库中引用另一个库时，最好通过Nx的命令来维护依赖：

• 如果是新创建库，用nx g @nx/js:lib lib2 --importPath @my-workspace/lib2，生成时会自动配置别名和依赖规则。
• 如果是已有的库添加依赖，运行nx add dependency --project lib2 --dependency @my-workspace/lib1，Nx会自动更新工作区的依赖图和TS配置。

如果已经手动添加了导入，运行nx reset清理Nx的缓存，再执行nx affected:build，让Nx重新扫描并更新依赖关系。

为什么LLM会建议修改rootDir？ #

这个方案是普通TypeScript单项目场景下的临时 workaround，但完全不适用于Nx的多项目工作区。Nx通过tsconfig.base.json的路径映射机制，已经完美解决了跨库导入的TS类型问题，不需要破坏每个库的独立rootDir。

总结 #

• ❌ 不要修改每个库的rootDir：这会把所有库合并成一个大项目，破坏Nx的隔离性和构建缓存特性，绝对不是最佳实践。
• ✅ 正确的Nx-native方式：使用工作区别名导入，确保tsconfig.base.json的paths配置正确，让Nx管理库之间的依赖关系。

备注：内容来源于stack exchange，提问作者Christian Vincenzo Traina