对于前端同学来说，业务组件库绝对不陌生，很多前端团队都会选择搭建业务组件库来解决跨项目复用业务组件，同时统一代码实现，统一代码质量，提高业务开发效率。但是我发现，在明确了需求之后，在开始调研技术方案的时候，很多同学并不清楚要调研哪些技术点，具体方向如何找到解决方案，找到解决方案后要尝试哪些case，如何去解决。实施这些解决方案。整合等等。其实你不需要想的那么复杂，只需要按照以下三个技术的要点去做就可以搞定。第一步：“打基础”——业务组件库的整体架构设计第二步：“搭建主体结构”——业务组件库的基础技术设计第三步：“粉刷门面”——业务组件库你一定觉得这三点太宏观了，不好理解，那么接下来，我就来介绍一下这三个重点是什么。可以参考这些重点进行相关的技术研究1.业务组件库的整体架构设计对于业务组件库的整体架构设计，核心问题是如何组织和管理业务组件库的代码.首先，我们构建代码库。业界普遍以单体仓库的形式维护同类型的组件库，将组件开发成npm包。这里的关键点是，你应该考虑将所有组件打包成一个大的NPM包，或者拆分成一个独立的小NPM包。**不要小看这个问题。这两种选择都会造成仓库目录结构的很大差异，进而影响后续组件的开发、构建、发布和实施。技术设计的单包架构是怎样的？如果选择Treatallcomponentsasawhole并将它们打包在一起发布。这称为单包架构。单一仓库，单一包裹，统一维护，统一管理。比如Antd最大的优势就是可以通过相对路径实现组件和公共代码之间的引用。缺点缺点是组件完全耦合在一起，必须作为一个整体进行封装。即使只是更改了一个组件的很小的功能，也必须为整个包发布更新。比如antd，就是作为一个整体来管理的。如果选择使用单包架构，那么必须提供按需加载的能力，以降低用户的成本。可以考虑支持ESModules的Treeshaking功能，实现按需加载的能力。当然，你也可以选择另一种解决方案，称为“多包架构”。多包架构是各个组件相互独立，单独打包发布，多个包在一个仓库，统一维护，单独管理。.├──lerna.json├──package.json└──packages/#所有的子repo目录都会存放在这里├──project_1/#Component1package│├──index.js│├──node_modules/│└──package.json├──project_2/#packageofcomponent2│├──index.js│├──node_module/│└──package.json...代码优势它最大的优点是组件发布灵活，并且天然支持按需使用，缺点是组件之间存在物理隔离。对于相互依赖、公共代码抽象等场景，只能通过npm包引用来实现。--这些场景统一发布开发相对不方便。多包架构在业界被称为“Monorepo”。在前端领域，我们一般使用第三方库Lerna来维护这样的架构。针对存在依赖关系的场景做了一些特殊的优化。在开发模式下，它会将所有依赖包以软链接的形式连接在一起，方便本地开发和联调。所以这就需要你考虑清楚组件库中的组件是否相互依赖。如果是这样，你可以通过Lerna来处理它。如果专门验证组件之间的依赖关系，也可以选择“单包架构”2.业务组件库的基本技术能力确定了整体架构后，就可以着手具体功能点的实现了。业务组件库需要整体框架提供五种基本技术能力1.构建能力这需要我们提供构建产品的能力。这里有很多选项，你可以选择Webpack，RollupGlupGrunt....构建组件库推荐使用Rollup。推荐使用Webpack来构建项目。这里需要特别注意产品的格式要求，比如我们常用的cjs、esm、umd格式。比如你的组件考虑支持node环境，比如SSR，你需要把代码打包成cjs格式。如果你的组件考虑支持
