主要是借鉴 nestjs 模块化的概念，来组织 react 的整体结构，将依赖拆分到 core 以及 common 基础包，来实现 react 代码的模块化开发

背景

前端项目的迭代逐步往复杂化以及多样化来发展，一个前端组十几二十个项目都很常见，后续维护起来全是灾难，代码的组织架构都在不断的迭代

此外即使内部开发了组件库来做代码共享，很多时候也是单纯的 UI 组件，无法包含请求以及复杂的业务逻辑， 而纯 UI 组件对于组内而言相对价值没有那么大，很多时候需要的是一整套的业务逻辑的自由组合

因此很多人都在推行微前端，配合后端微服务，将专门的功能提取到专门的前端页面，这样前端只需要组合服务模块即可，可以说是简单直接

但是微前端实际上就是将项目小型化，十几个项目都维护不过来，现在拆成微前端只会更多，维护起来难度更大，当然也可以使用比如说 monorepo 去减少维护成本

微前端最大的优势在于可以将不同框架的项目无缝衔接在一起，但是大部分的前端组都统一了语言和技术栈，框架选型以及组件库的挑选基本上都是确定的，这个时候使用微前端，感觉只会增加使用成本

本项目更倾向于将底层的差异全都抹平，然后提供一套模块化的接口设计，只要适配这套接口即可实现跨项目的组合，实现一套 react 技术栈下的跨项目业务共享方案

设计

很多人推崇微前端主要是认为巨石应用的开发跟维护都是灾难，但是个人认为，开发-构建-测试-部署这几个阶段应该区分开来，不能因为测试困难就要凭空增加开发的成本，而是应该将环节解锁，尽可能的提升每个环节的效率，这样才能成本最小化

从开发的角度来说，拿到需求然后针对性的开发测试，最后部署到成品库，这个就是最小路径，但是问题在于，前端从来都不是一个可以自由分割的部分，不可避免的依赖众多组件库，国际化跟状态管理无法脱离项目存在，webpack 这类还能用构建流程去处理，但是业务依赖则很难处理

因此我们首要解决的就是，如何将一个前端组件完整的隔离开来，同时又能方便的在测试环境与生产环境一致性复现，nestjs 的模块就十分适合这种情况，只依赖 core 包，同时能够随意迁移到任何项目

然后就是需要将模块组合的逻辑抽象成通用接口，这样就能实现模块自由组合，国际化和状态管理等核心逻辑存放在 core 包即可

但是一个问题在于，当项目庞大到了几是上百个模块的时候，可能会比较难维护，因此需要将模块一级级的分开，这样最外层项目只依赖一级模块，然后一级模块再依赖二级模块，层级上会比较清晰，唯一的难点就在于框架的开发需要支持模块的横向以及纵向拓展

这对构建也提出了比较高的要求，需要建立一个统一的构建平台，通过一定的条件自动触发构建，这样成本就完全能够接受

虽然能够解决开发的问题，但还是不可避免的会有部署的问题，业务模块如果包含了接口请求，那就不是静态模块了，需要做成动态模块，每次更新都会触发整个项目的更新，风险可能会有点大，但是这个从理论上来说，就是流程的问题了，只要保证开发的纯粹以及隔离，那么风险也是可控的

方向

到底是走 class 这种比较成熟的方案，还是走类似 react 的函数式这也是个问题，前者有大量可以借鉴的部分，后者则需要参考同类实现然后出一套类似的

不过话说回来，前者有 angular 这种比较完善的，重新做一套的意义也不大，还不如直接基于函数式的重新整一套，最起码契合 react 一点，也能有一点新意

两种都尝试一下，然后看看开发时哪种更友好吧

结构

• core: 核心逻辑，主要包含基础依赖，模块抽象以及组合逻辑等
• common：公共包，包括工具类以及请求类等
• plugins：插件包，一个完整的插件应该包含 核心的 middleware 和 模块的 hooks
• cli：脚手架，用于快速的开发和测试

模块

core

core 是核心部分，最开始将很多东西都打包进去了，但是仔细思考下，可以讲很多东西都剔除掉

plugins

plugins 是插件部分