干货 | 从0到1，搭建一个体系完善的前端React组件库

作者简介

 

剑桥，携程资深前端开发工程师，关注自动化工具开发、前端工程自动构建相关技术。

随着前端工程的发展，组件化的思想早已深入人心；现代的前端框架React/Vue等，都是围绕组件设计；组件化的开发模式，大大提高了开发效率；设计和开发高质量高复用性的公共组件，可以更好地保持产品迭代的高效和稳定。

我们以React的技术栈为背景，在日常的需求与迭代中， 历时两年多时间，沉淀出了携程用车各大产线（接送机/包车/打车服务等）的公共组件（机场、航班、城市、地址、时间控件等）。通过持续交付了一系列的组件库，让各个产线的开发小组不用再各自维护重复而难以迭代的代码，完成了前端组件与公共方法的收口，解决了用车前端业务组件一致性的问题。同时随着组件库工作流上的逐步完善，让前端开发同学脱离了刀耕火种的开发方式，进入了全新的自动化构建与高效开发的时代。

开发和维护一个可持续迭代的组件库，从来都不是一件容易的事情。本文将从组件库的基础搭建开始，从开发、打包、发布、拆包、优化、自动化测试等各方面，由浅及深地进行介绍，给大家分享一个相对完善的组件库落地的过程。同时也会介绍组件库的迭代过程中真正会遇到哪些问题，以及我们是如何解决这些问题的。希望这些实战中的经验，可以带给大家一些启发和想法。

 

一、实现最基础的npm发布流程

 

在组件库的设计之初，我们最先需要考虑的是，如何让npm包的发布流程安全、可靠可行。为了保证代码的安全性，公司内部会独立维护内网的npm管理平台。

在最早的发布设计中，我们仍然通过官方定义的cli命令，在本地通过设置registry指向内网仓库后，执行npm publish 进行发布。

可是对于公司内部而言，平台开放而BU众多，任何人都可以对任何已发布的包进行常规操作，这会带来一系列的不安全因素。最终在前端委员会的推动下，我司实现了内网npm与gitlab ci的关联。将发布操作迁移到了gitlab上，在发布权限上有一定的约束；通过开启npm deploy插件，以实现可视化交互式的发布管理，同时得益于gitlab hook的强大, 我们更是在流程实现了push event来触发auto publish，这一系列的进步，让我们的组件库在后续的发布流程上变得更加正式、稳定而可靠。

Npm关联gitlab后，通过指定指定分支下特定目录的package.json，实现版本升级后自动发布

 

二、组件库的打包处理

 

我们的技术栈涉及ReactWeb 与 React Native, 对于RN的代码，我们一般会走源码直接发布，RN项目中的编译过程会自动处理node_modules里的源文件。但是对于Web组件库而言，更传统的做法，则是需要在发布之前进行一些编译和转码，这样才能确保发布之后的npm包，可以在大多数环境下正常运行起来。

对于Web端组件库的打包，我们进行了多次的探索和优化。

使用webpack对每个组件进行单独打包，打包类型由umd改为commonjs2。

module.exports = {
    output: {
        filename: '[name].js',
        path: path.resolve(__dirname, '..', 'dist'),
        library: 'Tha',
        libraryTarget: 'commonjs2' // umd
    }
}

通常我们对组件库的建议是umd打包，因为这样可以实现多种模块方案的加载通用性。但在实践过程中发现，每个组件都需要单独打包时，UMD的打包方式，会显著增大每个文件的基础体积；而且我们99% 的场景下，其实已经并不用再去兼容AMD、CMD等模块加载