npm存在的问题

从架构的角度来看，将大型单体代码库拆分为较小的、独立封装的一系列模块通常是个好方法。从微服务到可复用组件库，很多技术都很适合模块化。但从版本发布和源代码管理的角度来看，它也可能是一场噩梦。

当项目有数十乃至数百个代码存储库时，发现工作也变得愈加困难。每当创建一个新的存储库，所有人必须将其添加到自己的代码模块中。
访问控制成了单调乏味的工作，且容易出错，尤其是得在“需要了解”的基础上一次一个地授予存储库访问权限，实在令人头疼。新员工经常要经历无止境的依赖项地狱。每个访问请求都会引出它们需要访问的另外两个存储库来。
高度模块化的架构也使版本控制变复杂了。我们可以让一系列相关模块的版本同步更新，给它们做“快照”（例如Babel和React就是这么做的）。但要让人们为那么多的包做这种工作（还包括和他们没什么关系的包）就是在自找麻烦。
包之间的依赖项重复会大大增加安装依赖项所需的时间。一些生态系统（特别是npm）是高度模块化的。模块化会鼓励复用，但也意味着某些包可能在你开发的每个包里都复制了一份。

解决方案

Monorepo是针对这个问题的流行解决方案。它意味着你会将所有模块放在同一个代码存储库中，而不是每个模块配一个代码存储库。然后开发者在开发应用时只用这个“monorepo”就够了。由于所需的内容都放在了一起，发现、访问控制和版本控制工作都变得更加简单。

显然，代价就是你只能对所有代码做整体权限控制。但如果你能接受这一点，monorepo就能在兼顾模块化所有优势的前提下提供非常简单的源代码管理方法。

那么monorepo怎样搭配npm使用呢？最受欢迎的两大解决方案分别是Yarn workspaces和lerna。由于lerna支持npm，让我们来看看它是如何实现monorepo的。

首先我们全局安装lerna。

$ npm install -g lerna

接下来，我们需要创建新的lerna存储库：

$ mkdir monorepo_example
$ cd monorepo_example
$ lerna init

查看lerna.json可以看到版本和包的定义位置。

$ cat lerna.json
{
“packages”: [
“packages/*”
],
“version”: “0.0.0”
}

如上所示，我们的monorepo中所有包的版本都是0.0.0。但是我们的monorepo中还没有任何包。在我们添加包之前应该先登录到我们的存储库，以便lerna在每个新包上正确设置publishConfig。

如果你要发布在公共npm存储库之外的位置上（例如npm Enterprise），则首先需要设置你的存储库。

$ npm config set registry https://registry.npm.yourcompany.com

接下来，我们用具有发布权限的用户登录到存储库中。如果你的包没有作用域，则可以省略-scope标志。

$ npm login -scope test

现在为我们的monorepo添加一些定域包（scoped package）。

$ lerna create @ test / a
$ lerna create @ test / b
$ lerna create @ test / c

如果你为每个包选择了默认设置，那么现在测试域内会有三个包（a、b、c），版本为0.0.0。在更新版本之前，我们需要提交已完成的工作的并为git创建一个远程连接：

$ git add。
$ git commit -m “Initial commit”
$ git remote add origin git@github.com:username/reponame.git
$ git push -u origin master

现在我们可以使用一个命令来更新所有包的版本。

$ lerna version major

此命令不仅会将每个包都更新到1.0.0，还会为你推送版本更新到git。最后一步是将这些包发布到npm。Lerna用一个命令就能完成这个任务。

$ lerna publish from-git

这条命令成功运行后，你就成功将第一个monorepo中的所有包都发布到npm了。万岁！

我们总结一下：

有关Lerna的更多信息，包括解决重复问题的方案，建议查阅他们提供优秀的文档。

我们也很高兴地宣布，我们计划为npm@7带来一流的monorepo支持。如果你在搭配monorepo使用npm，我们需要你的反馈！请告诉我们你对目前的monorepo解决方案的看法。

编程愉快！