最近在做公司内部组件库的迁移，过程中有一些思考和沉淀，在此记录下来。这些思考不仅仅适用于组件库开发，也适用于开始一个公司内部项目之前的考虑。
Before You Start…
在开始做公司内部的组件库之前，其实我也纠结了很久到底要不要开始这个事情。需要考虑的方面有很多，我考虑的问题主要包括（但不仅限于）以下几点：
- 谁会用？
- 做组件库的目的是什么？
- 编写、维护组件库的成本有多高？
- 谁来维护？
当前公司已经有一个现成的、基于Vue 2.0编写的组件库。但是这个组件库存在一些问题：
- 组件样式已经不符合当前的设计规范
- 使用的Vue 2.0编写，公司技术栈已经开始转向Vue 3.0
- 组件不能实现按需引入，组件样式也不能按需引入
谁会用 & 目的？
公司现在维护的几个最主要的前端项目，从技术栈上可以分为Vue 2.0和Vue 3.0的两批。
使用Vue 3.0的项目，因为没有现成的组件库，基础组件也是各写各的。这些项目是主要的目标用户。对于这些项目，组件库的意义在于统一规范，增强代码重用性。
使用Vue 2.0的重点项目，基本上都引用了现有的组件库。这些重点项目大部分都同时选型了Typescript。这部分项目后续有可能会迁移至Vue 3.0，在此基础上考虑的话，基于Vue 3.0的组件库是业务项目迁移的基础工作。这是新版组件库的次要目标用户。
考虑清楚谁会用、谁来用，是做这种公司内部业务抽象的重要原则。没人用的基础设施，等于昂贵的浪费。当然，如果这是为了你的KPI考核，那就是另一回事了。
编写、维护成本
由于已经存在现成的组件库，并且需要对跨Vue版本迁移用户友好，编写时会考虑尽量保持原有的组件API变化尽可能小。同时，在现成组件库上做迁移，也是代码复用，降低编写成本的考虑。
样式上，新的组件库需要更新为新的设计规范的样式。
对于现成的组件库来说，单组件的代码不会很多，再加上有完善的单元测试和文档，后续维护成本应该可以接受。
技术需求
在谈论技术选型之前，也要考虑技术需求。也就是——我希望这个组件库能具备什么特性，这个特性能给使用组件库的项目带来什么收益？这也是谈论技术选型的前提条件。
而对于组件库来说，最常见的技术需求主要有：
- 是否需要具备按需引入的特性。
- 是否适用于服务端渲染
支持按需引入可以说是现代组件库的必要条件之一，否则你的用户就会在只想引入一个button组件时引进来一大堆没有用到的依赖和样式。支持服务端渲染则需要更多考虑。在代码编写和测试时，都要处处考虑到SSR场景。对于我司的组件库而言，这两个技术需求都是必要的。
技术选型服务于技术需求。任何需求都是需要付出代价的。如果你不清楚自己的需求，你可能会走上弯路——组件库不能满足使用方的需求导致被弃用，又或者是实现了超出需求的feature，这个feature没有被用到但为此付出不菲的维护成本。因此考虑清楚技术需求是技术选型的前提条件。
其他可能需要被考虑但这里没有讨论的技术需求可能有：
- i18n
- a11y
- rtl
技术选型
组件库的技术选型主要有以下几种：
- 框架选择
- 样式组织方式（Sass / Less / 其他 CSS in JS方案）
- 写法（JSX / Template with Options API / Template with Composition API）
框架选择——我们要做的是Vue 3的组件库，那么自然选择Vue 3是必然的。这里重点讨论样式组织方式和代码写法两点。
样式组织方式
讨论样式组织方式前，我们可以看下当前流行的组件库是怎么组织样式的。
Ant-design-vue
框架上使用Less编写样式。公共样式放在了component/styles中，每个组件在自己的styles目录下编写样式，在styles/index.tsx中统一引入，方便用户使用时一次性把引入。
naive-ui
使用了聪哥自己编写的CSS-Render框架，可以参考他在知乎上的专栏文章：**css-render，另一种 CSS-in-JS 的方式。**
因为NaiveUI的需求是要能够在用户端接受用户的CSS的输入并且生成样式，传统引入Sass的方式体积过大，因此聪哥写了这个CSS-Render的框架来实现他的需求。
样式文件组织上和antdv是类似的。
element-plus
框架上用的是Sass编写样式。代码组织上，element-plus将全部样式放在了theme-chalk中，在组件的styles/index.ts中使用alias引入。本质上是一样的组织方式。
上面这些组件库普遍采用这样的组织方式，一来是项目结构清晰明了，维护方便，二来也是为了按需引入组件样式考虑。
写法
原来的组件库用的是Options API的写法。新的组件库计划改用TSX的写法来实现。考虑原因对于组件库开发而言，TSX可以提供更多的灵活性，为日后的需求实现留下空间。
我认为写法是完全取决于开发者/维护者团队的个人喜好的。注意——是团队。
其他
其他的一些不那么重要的选型（作为企业内部项目），我认为从以下两个方面来考虑：
- 使用尽可能成熟、稳定的技术框架、工具、库。
- 如果框架、工具、库之间存在理念上的代差，则恰恰相反，应该尽量用新不用旧。
这两条原则，是从学聪的分享中记录下来的，受益匪浅。