从0到1搭建前端团队组件库（一） -- 架构搭建为了设计和功能的统一并且全平台复用，我们从老版Datlas中解耦了通用组

设计背景

Datlas1.x版本为了更好的在各个模块中复用一些基础的组件，写了组件库的第一版，集成在本地项目里，服务于Datlas1.x；

当Datlas2.x开始重构，交付项目增多，并且我们的产品多元化的时候，我们发现了组件库的问题，如果只集成在本地项目中，会导致很多项目都有大量重复的基础代码，并且难以维护；

为了设计和功能的统一并且全平台复用，我们从老版Datlas中解耦了通用组件，并且加以完善，诞生了目前正在使用的组件库2.0。组件库2.0版本优化了组件库的基础功能和视觉效果，增加了主题功能，丰富了文档使用样例，通过npm发版的形式来做组件库的更新；

随着组件库2.0的使用时间变长，我们发现了如下问题：

组件库更新频繁，往往是一个平台需要频繁的更新图标，导致组件库的版本号一直增大
组件库的部分功能基于部分老的基础库，想要扩展变得吃力
组件库文档很多人反馈看不懂
....

加之设计组对组件库的视觉规范进行了重新升级，和解决以上痛点，我们决定将组件库3.0的开发提上日程

解耦组件库与图标库
提供新的色彩库和全新的文档
重构部分组件

开发流程导图

架构介绍

组件库的架构设计拆分成：

|-- 图标库
|-- 组件库
    |-- 色彩库
    |-- 组件库工具库
    |-- 组件
    |-- 文档库
    |-- 测试
|-- cli工具库

图标库

但是我们当前业务所使用组件库，是根据业务需要逐步搭建的，里面的图标也在不断地更新。在很长一段时间内，我们也是采用让图标入库的方式，随组件库一同维护。设计团队新增的每一个图标，都需要委托组件库开发者让图标入库、提交、发版本、业务侧更新组件库版本。这样的做法所带来的问题，就是操作繁琐，效率低下，还会导致组件库的版本号飞涨，CHANGELOG 几乎清一色的“新增一个图标”，不利于整体维护。