Lerna is a tool that optimizes the workflow around managing multi-package repositories with git and npm.
这是来自lerna的github仓库的自我描述。大致意思就是他是一个用来管理multi-package项目的工具,通过使用git和npm(其实yarn也是支持的)
lerna是标准的mono-repo的工具,与普遍的multi-repo的组织架构有着显著的区别。
传统开发即是multi-repo的,即一个module一个仓库,比如公司内部提炼的常用工具、常用组件都是分开存放,开发的时候install在同一个项目里。
而mono-repo则是一个仓库包含整个项目的所有,分成多个package目录分开管理,统一处理相互依赖。比如Babel、react、angular等等知名的库都是采用了mono-repo的方式。比如babel,babel-cli、babel-core、babel-node等等工具都是放在了同一个仓库“babel”中的,而我们安装的时候实际上是yarn add @babel/babel-core这样的安装方式。这就是很典型的mono-repo的模式,整个babel的产品都内聚到了babel的整个仓库内。
对于新知识来说,最重要的一点就是是否值得使用?什么时候应该用?适合哪些情况?
首先,作为一个外包型产品公司的码农,我认为对新项目使用mono-repo是不值得的。或者说一开始学习的时候,我就一直以公司产品的角度来看待mono-repo,想了好久都不明白这么做的意义在哪里?公共组件如果在同一个项目中,那么新项目怎么办?是copy过去?还是干脆一个仓库把后续的新项目都包括了?
这显然是不合适的,而且把原有的问题变得更复杂了。主要在与一个冲突:外包型的公司产品是互不关联的,他们没有任何内聚在一起的理由。同时,公司自己提炼的组件、工具等,其实和做的产品也是没有内聚的理由的。新项目依赖公司提炼的东西,但是他们之间只是开发上的依赖而不是内在的概念性依赖。就好像babel-core和babel-compile这是概念性的强联系,即使他们并不一定直接依赖。但是我们的项目依赖了babel-core,这就是一种仅仅在开发上的依赖。
那么是否可以使用mono-repo呢?当然是可以的,作为公司本身,我们的公共组件、工具等等等等是完全内聚的,完全可以合并成一个mono-repo,然后新项目来依赖这个repo这是完全可以的。好处也是有的,工具自己的内部依赖随时都是一致的,可以保证了整个repo的稳定性。但是好处并不明显,不管是lerna宣传的版本号统一还是自动处理多package生成统一的changelog,这对于外包型项目都没有显著的好处。
所以,对于大多数外包型的项目,mono-repo都没有足够的好处,意义不大
其次,对于来源项目开发者来说,对大多数个人开发者来说也是不太适合的。因为个人项目大多数体积偏小、功能比较单一,可以说没有拆分的意义。毕竟不是每个人都能像尤雨奚大佬一样一个人维护一个超大的项目的(>﹏<)。
所以,mono-repo更适合那些大型开源项目,本身复杂性较高,多人维护需要保证相互间版本一致,同时功能复杂,大多数可以独立成单独的项目维护的开源项目