构建组件库的3个Lerna替代品
Lerna正在转手，谁也不知道它会发生什么，这里有3个你可能想考虑的替代品。
组件库是你想在一个项目中使用的UI组件的集合。它们在一起使用是有意义的，或者是因为它们背后的设计理念，甚至是因为它们共同的设计规则。在开发时，虽然它们的内部逻辑可能是相互独立的（例如，输入组件不需要DateSelector或DropDownList来工作），但将它们放在同一个资源库中是非常有意义的。毕竟，虽然他们的业务逻辑并不意味着是耦合的，但他们的风格和内部编码风格可能会受益于所有这些组件都在同一个单库中。
但可惜的是，当你有一组独立的组件，如果你不小心，都捆绑在同一个项目中，事情就会变得非常糟糕。
因此，你通常会使用一个外部工具来处理发布和版本管理你的独立组件等事宜。为此，你通常会使用Lerna，一个非常有名的、熟悉的（对许多开发者来说）工具，它有助于组织开发和发布一个包含多个迷你包的项目的工作流程。
但如果你不想使用Lerna呢？它的创造者和多年的主要维护者最近把火炬传给了别人。那么，有哪些替代Lerna的方法你可以尝试，而不是去使用一个可能很快就会改变方向的项目？
让我们来看看!
#1号位
我想介绍的第一个替代方案是Bit，这是一个开源工具（与Bit.dev的远程托管平台进行了原生集成），可以帮助你创建和分享原子组件。这意味着什么呢？就是说你可以从头开始建立独立的组件，或者提取你的代码部分，并在Bit服务器（如Bit.dev）上作为独立组件进行共享。这最后一点很关键，因为它允许你从一个已经在进行的项目中提取代码，并对其进行扩展和发布，就好像它是一个完全独立的第三方依赖。
Bit的一些亮点是：
- 你不需要提取代码来分享它。你 可以直接从你的资源库中导出一个组件。Bit允许你将你的一段代码识别为一个组件，并将其独立于你项目的其他部分。这反过来又帮助你简化了共享过程，因为你不需要建立一个单独的 repo，也不需要重新设计将这些文件导入项目的方式（Bit最常被用作从头开始编写组件的工具。在这种情况下，整个项目将是一个独立组件的集合）。如果你已经有了一个包含多个组件的monorepo，现在你想把Bit纳入其中，这就很了不起。你可以简单地告诉Bit哪个文件夹有哪个组件，它就会为你做剩下的事情
- 导入你的组件的人（而不是仅仅安装它们）也可以对它们进行合作，修改它们，并将它们导出到注册表。如 果你在同一个组织内作为一个团队工作，这将是令人难以置信的强大。这样，你就能够在不同的团队中对同一个工具进行协作，而不必在一个单独的项目中工作。导入一个Bit组件会带来代码，并将其复制到你的工作目录中（而不是一个讨厌的npm_modules文件夹，你不能对其做任何事情）。
Bit不仅仅是一个用于版本管理和发布单版本组件库的工具。相反，Bit允许你集中管理你在开发工作流程中要做的一切，当然是在编码之外。
让我解释一下：在一个典型的工作流程中，你会对你的组件进行编码，你会在Git中对它们进行版本管理，你会使用一个捆绑器在测试它们之前把所有东西放在一起，你会使用某种测试库（比如说Jest）。你还会使用依赖管理器，如npm、yarn、pnpm等......可能还会有一些额外的工具。
Bit有 "build"、"run"、"test "等命令，这些命令包裹了所有这些常见的动作，允许你配置和抽象这些工具的需求。你在构建一个React组件库吗？妙极了!只需设置一个默认的React工作空间!位，默认情况下，将为你配置一套这些工具。但最重要的是？你不需要关心，直到你因为特殊原因需要定制它们。否则，你可以简单地通过这些命令，对你的组件进行版本管理，并与世界分享，甚至不用关心你是否使用Yarn、NPM或PNPM。
如果你有兴趣，这里有一篇关于这个特殊用例的更详细的文章。
#2 Turborepo
Turborepo是一个基于JavaScript的单端口的构建系统。这意味着，如果你想避免走Lerna路线，这正是你想要的东西。这个工具是专门为处理同一代码库内的多个项目而建立的。
你可以用它来从头开始创建一个全新的多项目，或者把它添加到一个需要一些内部秩序的现有单项目中。显然，使用create-turbo包（用npx create-turbo@latest ）从头开始总是更容易，但我们都知道这并不总是可能的。
不管你怎么开始，你很快就会开始配置构建管道，这也是Turborepo的核心。你的管道将决定每个环境的构建依赖性（比如 "测试"，你要确保除了测试结果外没有真正的输出，或者 "构建"，你要配置在生产中使用的输出目录，等等）。
Turborepo的一些关键方面，你在做决定时要考虑到：
- 它使用的是增量构建。这意味着，如果你在上次构建后没有修改过你的项目中的每一个文件，你就不必再构建它们。这对大型项目来说是一个很好的节省时间的方法，否则每次你做一个小的改动都要花很长时间来构建。
- 这也是在利用你所有的CPU核心。这可能看起来是一件很愚蠢的事情，但并不是每个系统都能利用你的CPU中的每一个核心，从而错过了通过并行任务获得的性能。
- 基于常规的配置。这个可能不是你的那杯茶，但我喜欢它。这基本上意味着，在默认情况下，它很清楚该做什么和怎么做。如果你坚持使用预设的约定，你将不必过度配置任何东西，只需抛出一些带有几行代码的JSON文件，该工具就能完成剩下的工作。
当然，Turborepo还有更多的功能，但如果这个快速的描述吸引了你的眼球，一定要去看看。
如果你喜欢到目前为止所读的内容，请考虑订阅我的免费通讯"一个老开发者的呓语"，直接在你的收件箱中获得有关IT行业的定期建议。
#3 Yarn工作区
如果你没有一个非常复杂的需要大量协调的多包项目，你可能会从更 "基本 "的东西中受益。
从1.0.0版本开始，Yarn实现了他们所谓的 "工作空间"。这是一种机制，允许开发者定义一个具有多个子包的单一项目，其中一些子包甚至是相互依赖的。
工作区带来的两个主要好处是：
- 简化依赖性管理。虽然所有的子项目都会有一个单独的package.json文件，但它们都会被Yarn同时协调（一个yarn安装就可以完成所有项目）。这反过来又简化了整个安装过程，并减少了任何可能出现的依赖版本冲突的机会。
- 软件包之间的依赖关系可以通过在内部创建符号链接来轻松解决。这大大减少了重复的文件
你可以把Yarn工作空间看作是Lerna等工具的构件，事实上，后者实际上合并了一个PR，更新了其内部逻辑以使用Yarn工作空间。
要使工作空间发挥作用，只需在根文件夹的package.json文件中的workspaces键中定义它们。
现在，你必须在你的项目根目录下创建3个不同的文件夹，名称完全一样（"一"、"二"、"三"）。每个文件夹都将包含自己的package.json文件和它的依赖项。以后将由Yarn来解决一切问题。
如果你想尽量减少工具的使用，这绝对是一个很好的选择，因为你可能已经在使用Yarn了。
Turborepo、Yarn工作区和Bit之间的主要区别在于，后者是一个完整的解决方案。Bit的目标不是成为你已经错综复杂的开发工作流程中的另一个工具，而是试图成为你需要担心的唯一工具。这是一个相当大的目标，但根据我的测试，它做得非常好
在大公司内部建立一个组件库可能真的很有挑战性，尤其是当你使用一个单程序的时候。不要误会我的意思，这绝对不是一个错误的方法，单片机在这种情况下有很多优势，但话说回来，工具是这种情况下成功的关键。
你正在使用什么工具来简化你公司的构建和版本控制任务？你打算暂时坚持使用Lerna吗？或者你正在尝试新的替代方案？
