跳至主要内容

传统包管理

在 lerna v7.0.0 中，我们默认删除了 lerna 中的 `lerna bootstrap`、`lerna add` 和 `lerna link` 命令。

本节介绍如何最好地停止使用它们，并使用包管理器 `workspaces` 对您的设置进行现代化改造。有关此操作 *必要性* 的完整背景信息，请参见下面的 背景。

重要的思维转变是认识到 lerna 不负责在您的仓库中安装和链接您的依赖项，您的包管理器更适合执行此任务。

实现此目标的方法是使用包管理器的 `workspaces` 功能。请参阅此处各自的文档

通过使用 `workspaces`，您的包管理器将执行与 `lerna bootstrap` 和 `lerna link` 之前为您执行的完全相同的链接操作，只是它已内置到 `install` 命令中。运行安装后无需执行其他命令（只要您按照上述包管理器文档配置了 `workspaces`）。

替换 `lerna add` 也是同样的道理。添加和删除依赖项是您的包管理器已经为您完成的操作，并且由于 `workspaces` 是一个一等用例，您可以运行适当的 `install` 命令将依赖项添加到特定的包/工作区，同样，所有相关的本地链接都将自动进行。

请参阅下面的更多具体比较以及使用前后的用法。

它有什么作用？​

lerna bootstrap 用于代替 `npm install`（或 `yarn` / `pnpm`）。它将安装所有外部包并在工作区内链接所有内部包。`lerna link` 将仅执行此操作的内部链接步骤。

在哪里可以找到它？​

它很可能位于工作区根目录下的 `package.json` 的“scripts”属性中。还要检查您的 CI 管道，因为它们也可能在 `npm install`（或 `yarn` / `pnpm`）的位置调用 `lerna bootstrap`。

我用什么来替换它？​

用 `npm install`（或 `yarn` / `pnpm`）替换 `lerna bootstrap`。如果您在之前调用 `lerna bootstrap` 的位置之前的工作流程中已经执行了包管理器的安装命令，则可以将其删除。`lerna link` 可以直接删除，因为链接步骤现在由您的包管理器在 `npm install` 期间处理。

信息

如果您正在使用 `yarn` 并依赖于链接二进制文件，则在切换到工作区后可能需要删除一次 `node_modules` 文件夹。有关详细信息，请参阅 此 yarn 问题。

替换您对 `lerna add` 的使用​

它有什么作用？​

lerna add 用于向工作区中的包添加依赖项。它将更新每个包的 `package.json` 文件以添加依赖项。

在哪里可以找到它？​

虽然通常手动调用，但 `lerna add` 可能会在工作区根目录下的 `package.json` 中的一些脚本中找到。

我用什么来替换它？​

lerna add 大部分可以用 `npm install` 的变体（或 `yarn` / `pnpm`）替换。`lerna add` 最常见的用例是向工作区中的单个包添加单个依赖项。此命令如下所示

lerna add <dependency> --scope <package>

可以直接替换为

npm install <dependency> -w <package>

-w 标志告诉 npm 仅在由 `<package>` 指定的工作区包中安装依赖项，类似于 Lerna 的 `--scope` 选项。

如果需要向多个包添加依赖项，则可以多次使用 `-w` 选项

npm install <dependency> -w <package1> -w <package2>

自定义提升​

Lerna 的传统 `bootstrap` 命令的一个优点是它为您提供了围绕提升或不提升某些依赖项到仓库根目录或将其保留在嵌套位置的控制权。

因此，如果您在包提升方面有相当自定义的设置，您可能会担心迁移远离 `lerna bootstrap`。

在我们测试各种包管理器的经验中，我们发现现代 `yarn`（即 v3 及更高版本）在提升控制方面提供了最大的灵活性

https://yarn.npmjs.net.cn/configuration/yarnrc/#nmHoistingLimits

我们还没有找到任何 `lerna bootstrap` 驱动的仓库，无论提升复杂性如何，都不能转换为现代 yarn，因此如果您适用，请尝试一下。

如果您只是在没有高级提升问题的情况下使用 `lerna bootstrap`，请随时从任何包管理器中选择，它们都提供了强大的 `workspaces` 实现。

临时填充传统包管理命令​

如果您确实发现自己陷入困境，并且在 v7 中需要 `lerna bootstrap`、`lerna add` 和 `lerna link` 的传统包管理命令，则可以在与您的 `lerna` 包相同的版本下安装 `@lerna/legacy-package-management` 包，这将使用旧实现填充这些命令。

需要注意的是，这只是一个权宜之计，这个新包可以被认为仅处于维护模式 - 不会考虑传统包管理问题（例如 `lerna bootstrap`、`lerna add` 和 `lerna link`）的新功能，我们只会考虑合并关键补丁和安全更新。

如果您发现自己处于这种情况，请在 lerna 仓库中打开一个问题，以便我们能够更多地了解您面临的困难并帮助您找到前进的道路

https://github.com/lerna/lerna/issues/new/choose

背景​

Lerna 是 JavaScript 生态系统中最初的单仓库/工作区工具。当它在 2015/2016 年创建时，生态系统看起来完全不同，并且没有内置功能来处理在单个仓库（“工作区”）中处理多个包。像 `lerna bootstrap`、`lerna add` 和 `lerna link` 这样的命令都是 lerna 项目的关键部分，因为当时没有其他选择。

然而，事实是，多年来，我们熟知的包管理器（`npm`、`yarn` 和 `pnpm`）都完全支持工作区作为一等用例的概念。

它们拥有经过实战检验的实现，涵盖添加、删除和链接本地包，并以自然的方式将它们与第三方依赖项结合起来。

这就是为什么在 Daniel 担任 lerna 主要维护者的最后几年里，他一直在鼓励人们认真考虑重新考虑他们在 lerna 中使用传统包管理命令的情况，而是利用他们选择的包管理器来完成其最擅长的工作。

我们从很早以前就了解到这种背景，但作为 2022 年项目的新维护者，我们不想直接跳进去开始移除功能，而是在花时间近距离了解实际情况之前。现在，我们已经积极维护了一段时间，我们完全同意 Daniel 和其他人的观点，即 Lerna 中的旧版包管理命令需要被弃用。

通过移除这些在包管理器中拥有更好替代方案的旧版组件，我们和 Lerna 社区中的其他成员现在可以腾出精力专注于 Lerna 独有的宝贵功能（例如但不限于版本控制和发布），并使它们达到最佳状态！

信息

如果您有任何具体问题，请访问 Lerna v7 讨论，在其中提供尽可能多的信息！