在开发大型项目时，我们通常会遇到同一项目依赖不同组件软件包的问题，同时，不同的组件软件包仍将相互依赖。那么如何管理组织是一个迫在眉睫的问题。
我们现有的解决方案是：MultirePo（多个相关软件包独立执行GIT管理）和MonorePo（所有依赖的库都完全放入项目项目中）。
MultirePo的缺点是，在更改每个库后，需要在线发布，然后重新安装，包装，发布该项目，最后更新。这样，依赖性就越复杂，要维护的困难越困难。
为了解决上述问题，此工具是诞生的，并且可以轻松地管理使用多个软件包的JavaScript项目。允许团队的其他成员构建组件文档和演示。
我们总结上述上述问题：
接下来，我将回答上述问题。如果您想查看实际情况，则可以参考：
这个问题主要使用我上面提到的Lerna工具来解决。目前，我们熟悉Babel，Create-React-App，Vue-CLI等，所有这些都使用Lerna。
当不使用Lerna时，我们不同库的组织形式可能如下：
使用Lerna后的图书馆组织结构：
上面的两个是我制作的简短地图，它基本上可以比较使用Lerna之前和之后的差异。Lerna的作用是将多个项目或模块分为git仓库中的多个软件包，我们可以使用它可以轻松管理不同项目的命令，如下：
同时，Lerna还将根据GIT提交记录，以自动生成ChangElog。当然，Lerna还提供了许多有用的订单。如果您有兴趣，可以在官方网站上学习。
接下来，我将带您构建由从头开始管理的Lerna管理的多包装项目。
上图显示了我们的书包的依赖。首先，我们需要安装Lerna Global。
创建的每个软件包的目录结构如下：
从上面显示的3个包的依赖性中，我们需要安装目标安装，如下：
因为Libb取决于LIBA，因此我们可以使用Lerna add来指定安装范围来指定安装范围。
其余可以用上述方法执行。当我们编写响应包的代码时，我们还可以使用：
在NPM上发布了包裹。根据我们选择的管理模式，所有软件包的版本编号将根据lerna.json.json.json.json.json.json.json.json.json.json.json的版本进行更新。
此模式会自动将所有软件包包装在一起，并且其中任何一个或更多软件包的重大更改将更新所有软件包的版本号。
独立模式，当init时，您需要设置独立于选项的模式。此模式允许用户为每个软件包分别更改版本编号。每次执行Lerna public public，对于所有更新的更新包，您都会询问一个一个。一个。基准版本是其自己的package.json.json.json.json.json.json的版本编号不会更改，默认值是独立的。我们可以指定Lerna初始化时：
有关特定情况，请参阅：https：//github.com/mrxujiang/best-cps
对于组件文档，市场上还有许多开源工具，例如Vue-Press，Storybook，Docz等。因为我最近的项目主要是反应，所以我在这里使用DUMI。我一直在模块组件之前共享滑动验证代码组件。
以下是在Lerna项目中集成DUMI之后文档网站的效果：
ESLINT代码规范。我认为每个朋友都不陌生。我们只需要安装相应的插头-in并编写相应规则的配置文件。这是一个简单的例子：
配置后，我们需要设置测试时间。例如，在操作过程中运行或检查时，由于个人习惯和效率问题，我在提交时采用了检测。我们可以使用githook进行预审长测试。在这里，我们需要将以下命令添加到package.json文件：
配置后，我们只编写一行非常规代码，然后提交。终端将显示以下信息：
从控制台中，我们可以发现代码未标准化。如果我们不进行调整，则无法提交代码。这样
同时，上面提到了Githooks，这对Githooks来说也很有趣。它可以帮助我们在代码提交的不同阶段自定义操作。例如
如果您有兴趣，可以访问https://githooks.com，以获取有关Githooks的更多内容。
对于代码提交规格，我们还需要进行统一的管理，以便团队可以知道每个提交的内容，尤其是在多人游戏协作时。这里
出现上述提交格式不是统一或信息难以理解的问题的原因是由于缺乏规范性约束。
为了实现工程师提交的信息的检测，您需要使用commit-msg githooks。特定配置如下：
其余的就是commitlint.js所做的。这是我编写的Nodejs脚本，以检测用户提交的信息是否标准化。当然，您还可以根据此脚本定义自己的提交规格。具体效果如下：
我们可以看到，当我们提交一条不符合规格的消息时，终端控制台将打印以下提示信息并终止程序继续。
通过上述配置，团队不同成员的代码和提交信息将非常统一和标准化，并且项目的整体质量将得到改善。
如果您对视觉构造或低代码/零代码感兴趣，也可以参考我以前的文章或在评论领域交换您的想法和经验。欢迎探索前端的真正技术。