作为toB业务生态，长生命周期下来积累有自己的组件库是一件理所应当的事情。本文主要介绍创建和维护自己的UI组件所需要注意的方面几个方面。
开发框架
工欲善其事必先利其器，要造自己的轮子首先要有一个好用的开发框架。下面看看搭一个前端组件库需要的各方面：
本地调试
提到本地调试可能都会想到webpack的devServer，但是这里有点不同，组件库不是业务系统，没有统一的入口的渲染。所以，即使将强行将所有组件组装到一个统一入口暴露给devServer来调试也并不是一个太好的办法。那怎么调方便点？通常组件库会配套说明文档和demo，所以从demo来调试才是正确的姿势，后面文档生成一节会讲。
单元测试
业务级系统大多没有单元测试，但是组件库不一样，作为被其他项目大量使用的底层基础，单元测试的覆盖率是基本要求。
Jest + Enzyme是最为常见的测试组合，具体使用不展开。
文档生成
开源组件库如antd，ElementUI都有完善的文档说明，并在每个组件中附带demo还能查看代码，相当nice。当然这些都有现成的tool可以用，StoryBook、Docz等都是支持MDX（Markdown + jsx）语法的文档和demo编写工具，具体怎么使用可以上官网看一下，上手非常简单。
编译打包
作为组件库，支持按需加载是基本要求。然后，最常见的webpack编译组件库的话，有一点不好的是webpack(5)打包为ES Module还目前处在experiment阶段，所以要么每个组件配置一个entry，要么，使用其他的打包工具。
其实在组件库使用的更广的还是rollup和gulp作为打包工具，来输出支持按需加载的架构，最后npm pack压缩上传或者npm publish发布。
现成工具
曾经自己用gulp+Docz+jest+Enzyme再加一些插件搭了框架，虽然也不错，但是好心累。有没有现成的好用框架呢，阿里系的dumijs可以了解一下：开箱即用，支持MDX，支持Typescript类型定义生成，theme支持，同时支持移动端组件库开发。
开发过程
开发框架搞定了，接下来就是组件库开发了，一个合格的基础库需从可靠性，可扩展性，可维护性三方面入手，组件开发过程中需要注意以下几个：
可靠性
测试覆盖率
作为基础设置之一的组件库，是业务系统的基石，一般来说90%以上的覆盖率是必须的。
双端一致性
如果同时有H5端和PC端的基础组件库，那么这二套组件库在同一组件的行为和结果上需要保持高度一致。如果不一致，你可以想象会给业务层人员所带来的负担和混乱。
可扩展性
风格theme
一定要使用less/sass/css3 var的变量系统定义基础theme，包括：颜色，字体，字号，基础间距等。在各组件中通过引用已定义变量来作为基础信息。这不仅关系到组件输出的风格一致性，还涉及到后续的风格更新及UI规划。
参数及渲染
尽量考虑可扩展性问题，如方法的入/出参尽量用对象，渲染支持同时支持字符串和Dom等。
举个栗子:
<Panle title="myTitle" onClick={(params)=>{}}></Panle>
这个Panel组件支持title属性和onClick事件，那么title除了支持字符串之外还应该支持Dom，那么业务层就可以自己定义标题的渲染而不限定于字符串。onClick事件的参数应该进行返回为对象，比如{source: "es", value:"vs"}，后续如果需要抛出更多的东西就不用对参数表进行修改即可兼容以前的。
可维护性
文档和demo
这个是组件库必须的，后续接手或参与迭代的人通过文档和demo能够非常容易的上手。
代码注释
虽然有了文档和demo，但是必要的注释还是必不可少，特别是有些较为复杂的地方需写明思路为什么这么做，而口水话就不要写了，比如：
//处理panel的点击事件--错误的写法
//panel点击后改变颜色--正确
handlePanelClick = ()=>{}
管理模式
这里特指跟组件库相关的管理，通常需求会先经过UI做图再交给前端业务开发，UI做图的时候就需要有所依据。这个依据就是已有的组件库基础组件，不能随便使用未在组件库中的组件来做图，这会给业务端开发造成较大影响，前端组和UI组需要有定期的计划，由前端架构师沟通规划，就组件库进行迭代和新增。
有时候确实有一些较急的新组件需求，这时候UI组需要提前与前端进行沟通，可以同时进行，保证交付给业务层时有一个初版组件可用。
toB业务毕竟不像toC有很大的自由发挥空间，规划上还是比较好做的。
发布
首先一点就是，绝对不能在开发分支或feature分支发包，这一点可以通过在技术上加prehook同时管理上声明。同时在readme中重点指出，在非master发包会造成很多问题，因为你控制不了使用该组件库的人使用什么版本，如果你发布了不正确的包而且自己没意识到话，那么3.25向你招手了。
单元测试
发布前执行测试是基础库的必须项，但是这一项不一定需要在开发者本地完成，可以通过CI/CD流程聚合到git来做，通常在feature合并到release或release合并到master的时候强制触发跑test，如果不通过，则不能发包。
变更历史
变更历史可以手写，当然也可以通过MR根据commit消息自动生成，不过本人观点还是手写好一点，通常写changeLog.md
版本更新
没吃过猪肉也见过猪跑吧，breaking change一般是要升大版本号的，兼容性升级就看规划了，可升1位或2位。其实版本更新最麻烦的还是有大bug修复的情况，需要通知所有使用端同步升级，但问题是不知道谁用了，这个问题在toB生态中会规划到cli脚手架中来讲。
