您可能不需要 TypeScript 项目引用

名称: Jared Palmer
X: @jaredpalmer

如果您曾在大型 TypeScript 代码库或 monorepo 中工作过，您可能熟悉项目引用。它们确实非常强大。

当您在 tsconfig.json 中引用一个项目时，会发生新的事情

从被引用的项目导入模块将改为加载其输出声明文件 (.d.ts)
如果被引用的项目生成一个 outFile，则输出文件 .d.ts 文件的声明将在此项目中可见
运行构建模式 (tsc -b) 将自动构建被引用的项目（如果它尚未构建但又是必需的）
通过分离成多个项目，您可以大大提高类型检查和编译的速度，减少使用编辑器时的内存使用量，并改进程序逻辑分组的执行。

听起来很棒！对吧？！嗯...也许吧。一旦您向项目添加了引用，您现在就需要不断更新它们，每当您添加或删除包时。这有点糟糕。

嗯...如果您不需要这样做呢？

“内部” TypeScript 包

事实证明，您甚至可能不需要引用，甚至不需要中间的 TypeScript 构建步骤，使用我即将向您展示的一种模式，我将其称为“内部包”。

“内部包”是一个没有 tsconfig.json 的 TypeScript 包，其 package.json 中的 types 和 main 字段都指向包的未转译入口点（例如 ./src/index.tsx）。

package.json

{
  "name": "@sample/my-internal-package"
  "main": "./src/index.ts"
  "types": "./src/index.ts", // yes, this works!
  "dependencies": {
    ...
  },
  "devDependencies": {
    ...
  }
}

事实证明，TypeScript 语言服务器（在 VSCode 中）和类型检查器可以将原始 .ts 或 .tsx 文件视为其自己的有效类型声明。最后这句话在您读两遍后就显而易见了。然而，不太明显的是，您可以将 types 字段直接指向原始源代码。

一旦您这样做，这个包就可以在没有项目引用或 TypeScript 构建步骤（通过 tsc 或 esbuild 等）的情况下使用，只要您遵守 2 条规则

内部包的消费应用程序必须转译和类型检查它。
您永远不应该将内部包发布到 npm。

据我所知，无论您是否使用 Turborepo 或其他工具，这种内部包模式都适用于所有 yarn/npm/pnpm 工作区实现。我个人已经使用几种不同的元框架测试过这种模式（见下文），但我确信它也适用于其他框架。

Next.js

Next.js 13 可以自动转译和捆绑来自本地包（如 monorepos）或来自外部依赖项 (node_modules) 的依赖项。

next.config.js

/** @type {import('next').NextConfig} */
const nextConfig = {
  transpilePackages: ['@acme/ui', 'lodash-es'],
};
 
module.exports = nextConfig;

从 Next.js 13.1 开始，您不再需要 next-transpile-modules 包。有关更多信息，请访问 Next.js 内置模块转译博客文章。

您可能不需要 TypeScript 项目引用

“内部” TypeScript 包

Next.js

Vite

React Native

这种模式的优点

注意事项

说到漫长的构建时间...