前言
时间真快，7月又到20号了。今日早读文章由百度
LucasHC投稿分享。正文从这开始~~
随着业务复杂度的上升，前端项目不管是从代码量上，还是从依赖关系上都会爆炸式增长。对于单页面应用或者多应用项目来说，各个应用之间的关系也会更加复杂，多个应用之间如何配合，如何维护相互关系？公共库版本如何管理？如何兼顾开发体验和上线构建效率？这些话题随着前端业务的发展，逐渐浮出水面。
这篇文章我就以一个成熟的大型项目为例，从其中一个优化点延伸，谈一谈前端现代化开发和架构设计方式的思考和经验。当然，每一种风格的项目组织方式都各有特点，如何在这些不同架构下，打造顺畅的开发构建流程，持续优化提效是一个非常值得深入的话题。
多项目应用开发架构设计对于一个大型复杂的业务，如果我们将所有业务逻辑开发放在同一个Git仓库下，那么长久以往会导致项目臃肿不堪，难以维护。针对于此，历史上我们习惯将这个“超级Git仓库”，分散成多个小的Git仓库，一个项目拆分成多个应用。但是这样的做法并没有解决多个应用之间的耦合和公共逻辑的重复。甚至极端的场景下，如果应用之间具有强关联，这样的多仓库设计势必造成开发调试和上线的痛苦。
针对上述背景，目前更加现代化的前端管理风格和架构设计主要有两种（基于Gitsubmodule能力的方案不再本文考虑范围之内）：
基于Webpack多入口的项目拆分和多应用打包构建
基于Monorepo风格的项目设计
这两种解决方案都保留了这个唯一的“超级Git仓库”，但是它们的设计思想却有不同。我们可以简单理解为：
「基于Webpack多入口的项目拆分和多应用打包构建」更加适合于业务应用项目，在多项目内聚的前提下，保证了开发和调试的便利性，同时可以拆分构建和打包流程，显著提高效率
「基于Monorepo风格的项目组织」似乎更加适合库的编写，使用Lerna这种工具的Monorepo方案带有鲜明的发版能力和强烈的工程库风格。这种模式下，依然具有上述提到的开发和调试便利性，构建和打包的原子性，可谓「你喜欢的样子我都有」
这两种解决方案的原理和实现这里我不再赘述，感兴趣的读者可以订阅频道，后续我会详细解析，而本篇将会继续从另一种角度来持续深入。
MonorepoVSMultirepo由于下文涉及到的场景采用了Monorepo风格的管理方式，且这是我个人非常推崇的方案，因此这里我稍微介绍一下相关概念。对于相关概念已经有过了解的读者，可以直接跳过这部分，进行下部分的阅读。
现代管理和组织代码的方式主要分为两种：
Multirepo
Monorepo
顾名思义，Multirepo就是将应用按照模块分别管理在不同的仓库中；而Monorepo就是将应用中所有的模块全部一股脑放在同一个项目中，不再需要在单独发包、测试，且所有代码都在一个项目中管理，在开发阶段能够更早地复现bugs，暴露问题，更方便进行调试。
这是项目代码在组织上的不同哲学：一种倡导分而治之，一种倡导集中管理。究竟是把鸡蛋放在同一个篮子里，还是倡导多元化，这就要根据团队的风格以及面临的实际场景进行选型。
我试图从Multirepo和Monorepo两种处理方式的各自弊端说起，希望给读者更多的参考和建议。
对于Multirepo，存在以下问题：
开发调试以及版本更新效率低下
团队技术选型分散，有可能不同的库实现风格存在较大差异
Changelog梳理困难，issue管理混乱（对于开源库来说）
而Monorepo缺点也非常明显：
库体积超大，目录结构复杂度上升
需要使用维护Monorepo的工具，这就意味着学习成本
社区上的经典选型案例：
Babel和React都是典型的Monorepo他们的issue和pullrequest都集中到唯一的项目中，changelog可以简单地从一份