背景在开发大型项目时，我们经常会遇到同一个项目依赖不同组件包的问题，??而不同的组件包又相互依赖，那么如何管理并组织好这些依赖包是一个迫在眉睫的问题。我们现有的解决方案是：Multirepo（多个依赖包由git独立管理）和Monorepo（所有依赖库完全放到一个项目工程中）。Multirepo的缺点是每次库更改后，都需要发布到网上，然后在项目中重新安装，打包，发布，最后更新，这样依赖越复杂，越难维护。Monorepo最大的缺点就是不方便代码复用和共享。为了解决以上问题，诞生了工具lerna，它可以轻松管理多个包的JavaScript项目。同时，对于组件包的开发者和维护者来说，为了让团队中的其他成员更好的理解和使用我们开发的组件，构建组件文档和demo是极其重要的。对以上问题做一个总结：大型项目中如何管理和组织依赖包及其版本如何高效低成本地构建简单易用的组件文档看实际案例，你可以参考：best-cps|基于lerna+dumi的多包管理实践大型项目中如何管理和组织依赖包及其版本这个问题主要是通过我上面提到的lerna工具来解决的。目前我们比较熟悉的babel、create-react-app、vue-cli等都是用lerna。在不使用lerna的时候，我们不同库的组织结构可能是这样的：使用lerna后的库组织结构：上面两个是我做的lerna的示意图基本可以比较一下使用lerna前后的区别。lerna的作用是将多个项目或模块拆分成多个包，放到一个git仓库中进行管理。我们可以使用它提供的命令轻松管理不同的项目，如下：lernaboostrap自动解析包之间的依赖关系，对于包的内部依赖直接使用symlinks。lernapublish依赖git检测文件变化并自动发布，管理版本号根据git提交记录的变更日志。当然lerna也提供了很多有用的命令，感兴趣的可以去官网学习。接下来，我将带大家从零开始搭建一个由lerna管理的多包项目。上图展示了我们包的依赖关系。首先，我们需要全局安装lerna。项目初始化$gitinitbest-cps&&cdbest-cps$lernainit创建三个包$lernacreateLibA&&lernacreateLibB&&lernacreateBaseUI每个包的目录结构如下：LibA├─tests│└─dooring.js├─lib│└─dooring.js├─README。md└─package.json安装对应包的依赖。从上面显示的三个包的依赖关系来看，我们需要针对性的安装，如下：$lernaaddLibA--scope=LibB因为LibB依赖于LibA，我们可以通过--scope来使用lernaadd来指定安装范围。例如，BaseUI同时依赖于LibA和LibB包。我们可以使用下面的命令：$lernaaddLibALibB--scope=BaseUI其他人按照上面的方法即可。当我们写完对应的包的代码后，我们还可以使用：$lernapublish来一键发布包到npm。这里根据我们选择的管理方式，所有包的版本号都会根据lerna.json中的版本号进行更新。但是我们需要注意的是，lerna版本更新支持两种模式：fixed/lockedmode（默认，指定版本号）这种模式会自动将所有package包版本捆绑在一起，对一个或多个package的任何重大改动都会导致要更新的所有包的版本号。独立模式（independent）在独立模式下，需要在init的时候设置选项--independent。此模式允许用户单独更改每个包的版本号。每次执行lernapublish，对于所有更新的package，都会一一询问需要升级的版本号，baseversion就是自己的package.json中的版本号。这样的话，lerna.json的版本号是不会变的，默认是独立的。我们可以在初始化lerna的时候指定：lernainit--independent具体情况可以参考：https://github.com/MrXujiang/best-cps如何高效低成本的构建简单易用的组件文档对于component文档，市面上也有很多开源工具，比如vue-press、storybook、docz等，因为我最近的项目大部分都是react，这里我用的是dumi。之前在分享滑动验证码组件的时候给大家分享了dumi的使用。可以参考我之前的文章：从零开始开发一个轻量级的滑动验证码插件下面是lerna项目中集成dumi后的文档站点效果：如何配置eslint代码规范和代码提交规范eslint代码规范我觉得各有各的小伙伴们并不陌生，我们只需要安装相应的插件并编写相应规则的配置文件即可，这里举个简单的例子：//.eslintrc.jsmodule.exports={extends:[require.resolve('@umijs/fabric/dist/eslint')],rules:{'import/no-extraneous-dependencies':0,'import/no-unresolved':0,},};配置完成后，我们需要设置检测时机，比如Run-timedetection或者commit-timedetection，由于个人习惯和效率问题，我采用commit-time检测，即开发者功能开发完成后，检测是在执行gitcommit的时候进行的，我们可以使用github来做pre-commit检测，这里需要在package.json文件中加入如下命令："gitHooks":{"pre-commit":"npmrunlint:js“}。配置好之后，我们就可以写一行非标准代码提交了。终端会显示如下信息：从控制台可以找到代码不规范的位置和原因。如果我们不做调整，代码是无法提交的。这样可以提高代码质量和错误概率，具有很大的长期价值。同时上面提到了Githooks。对于Githooks的知识也很有意思，它可以帮助我们在代码提交的不同阶段进行自定义操作，比如代码提交前的检查、代码提交信息规范等。常用的gtihooks有：pre-commitprepare-commit-msgcommit-msgpost-commitpre-rebasepost-mergepre-receiveupdate有兴趣的可以访问https://githubs.com获取更多关于githubs的信息内容。对于代码提交规范，我们也需要做统一的管理，让团队更直观的知道每次提交的内容是什么，尤其是多人协作的时候。下面是几个常见的不规则提交的例子：gitcommit-m'addpop-upwindow'gitcommit-m':updateupdate'gitcommit-m'fixfixabug'以上提交格式不统一的原因或者提交信息难理解是因为缺乏规范的约束，所以对于大型项目或者多人协作的项目，最好统一规范，这样可以提前避免很多不必要的麻烦。实现对工程师提交信息的检测，需要用到githooks的commit-msg，具体配置如下："gitHooks":{"pre-commit":"npmrunlint:js","commit-msg":"node./commitlint.jsverify-commit"}剩下的就是commitlint.js做的事情了，就是我写了一个nodejs脚本，检查用户提交的信息是否规范。当然你也可以根据这个脚本定义自己的提交规范。具体效果如下：我们可以看到，当我们提交了一条不符合规范的信息时，终端控制台会打印如下提示信息，并终止程序继续。通过以上配置，团队不同成员编写的代码和提交信息会非常统一和规范，项目的整体质量也会得到一定程度的提升。以上是基于lerna+dumi+eslint+commit的实践我已经发布到github上，大家可以参考学习，欢迎提出更好的建议。
