多工程多Bundle方案

　　多工程多Bundle方案的意思就是一个Git库中存放了多个页面文件夹，各个文件夹是完全独立的关系，各自是一个完整的前端工程。拥有自己独立的MRN配置信息、package.json、组件、Lint配置等（如下图所示）。每个页面文件夹都输出一个独立的RN Bundle。

　　相比于单工程单Bundle方案，多工程多Bundle方案将页面进行解耦，使之基本可以满足中大型MRN项目的需求。在外卖MRN项目初期，一直都使用着这样的工程结构进行开发。但是我们也为之付出了相应的代价，即每个页面的依赖都需要对应RD去维护升级，依赖碎片化的问题日趋严重。同时在工程级别的管控，如统一Lint规则、Git Hook等也变得更加复杂。

　　多工程多Bundle方案 => 单工程多Bundle方案

　　随着外卖MRN页面规模以及参与人规模的进一步增大，多工程多Bundle方案的缺点日益凸显。特别对于那些前端技术底子相对薄弱的团队来说，依赖管理问题会变得很头疼。在这种情况下，单工程多Bundle的方案就应运而生了。

　　核心思路也很简单：观察一下单工程单Bundle方案和多工程多Bundle方案的优缺点可知，单工程单Bundle依赖管理方便的优点主要来自于“单工程”，而多工程多Bundle的业务解耦的优点主要来自于“多Bundle”。所以结合这两种工程方案的核心优点，就可以设计一种新方案：单工程多Bundle。即用一个工程去承接所有的页面代码，但是又可以让每个页面输出独立的RN Bundle来保证互不影响。其实，这种方式类似于Native一个静态库的管理，如下图所示：

　　通过分析MRN的打包原理可知，MRN通过一个配置文件配置了一个Bundle的所有业务信息以及mrn-pack2的打包入口。所以我们只需要让配置文件支持多份Bundle信息的配置，通过打包命令与参数选择正确的mrn-pack2打包入口，即可打出我们*终所需要的业务Bundle。如下图所示：