管理依赖项

外部依赖 来自 npm 注册表，允许您利用生态系统中的宝贵代码，从而更快地构建应用程序和库。
内部依赖 让您可以在存储库中共享功能，极大地提高了共享代码的可发现性和可用性。我们将在下一篇指南中讨论如何构建内部包。

./apps/web/package.json

{
  "dependencies": {
    "next": "latest", // External dependency
    "@repo/ui": "workspace:*" // Internal dependency
  }
}

依赖安装的最佳实践

在需要的地方安装依赖

当您在存储库中安装依赖项时，应直接将其安装在使用它的包中。该包的 package.json 将包含该包所需的所有依赖项。外部依赖项和内部依赖项都适用此规则。

须知：

请注意，您的包管理器可能会选择使用与包不同的 node_modules 位置。

要快速在多个包中安装依赖项，您可以使用包管理器

终端

pnpm add jest --save-dev --recursive --filter=web --filter=@repo/ui --filter=docs

→ pnpm 文档

这种做法有几个好处

提高清晰度：当一个包的依赖项列在其 package.json 中时，更容易理解它依赖于什么。在存储库中工作的开发人员可以一目了然地看到包内使用了哪些依赖项。
增强灵活性：在一个大规模的 monorepo 中，期望每个包都使用相同版本的外部依赖项可能是不现实的。当有许多团队在同一个代码库中工作时，由于大规模运行的现实，会有不同的优先级、时间表和需求。通过在包中安装其依赖项，您可以让您的 ui 团队更新到最新版本的 TypeScript，而您的 web 团队可以优先发布新功能，稍后更新 TypeScript。此外，如果您仍然希望保持依赖项版本同步，也可以做到。
更好的缓存能力：如果您在存储库的根目录中安装了过多的依赖项，每当您添加、更新或删除依赖项时，都会更改工作区根目录，从而导致不必要的缓存未命中。
修剪未使用的依赖项：对于 Docker 用户，Turborepo 的修剪功能可以从 Docker 镜像中移除未使用的依赖项，从而创建更轻的镜像。当依赖项安装在它们预期的包中时，Turborepo 可以读取您的 lockfile 并移除您需要的包中未使用的依赖项。

根目录中的少量依赖项

遵循上述第一个原则在需要的地方安装依赖项，您会发现工作区根目录中的依赖项自然会很少。

仅属于工作区根目录的依赖项是用于管理存储库的工具，而用于构建应用程序和库的依赖项则安装在各自的包中。一些适合安装在根目录的依赖项示例包括 turbo、husky 或 lint-staged。

管理依赖项

Turborepo 不管理依赖项

请注意，Turborepo 不参与管理您的依赖项，这项工作将留给您选择的包管理器来完成。

下载正确的外部依赖项版本、符号链接和解析模块等事情都由包管理器负责处理。本页上的建议是在工作区中管理依赖项的最佳实践，并且不受 Turborepo 的强制执行。

包管理器之间的模块解析不同

包管理器具有不同的模块解析算法，这会导致行为差异，难以预测。

在 Turborepo 文档中，我们根据包管理器预期的行为提出许多建议。我们对如何处理依赖项的介绍是尽力而为，您可能需要根据您的包管理器或存储库的需求调整记录的行为。

但是，如果您发现文档中存在对所有包管理器或特定包管理器似乎普遍不正确的错误，请通过 GitHub Issue 告知我们，以便我们改进。

node_modules 位置

根据您选择的包管理器、版本、设置以及您在工作区中安装依赖项的位置，您可能会在工作区内的各种位置看到 node_modules 及其内部的依赖项。依赖项可能位于根目录的 node_modules、包的 node_modules 或两者都有。

只要您的脚本和任务能够找到它们所需的依赖项，您的包管理器就正常工作。

在代码中引用 `node_modules`

工作区内 node_modules 的具体位置不是包管理器公共 API 的一部分。这意味着直接引用 node_modules（例如 node ./node_modules/a-package/dist/index.js）可能会不稳定，因为依赖项在磁盘上的位置会随着工作区周围的其他依赖项变化而改变。

相反，尽可能依赖 Node.js 生态系统的约定来访问依赖模块。