开发一个高质量的前端组件，这些姿势一定要知道

前言

2009 年 11 月 8 日，在欧洲 JSConf 大会上，Ryan Dahl 第一次正式向业界宣布了 Node.js 的面世，使 JS 语言书写后端应用程序成为了可能。在随后的几年里，Node.js 受到了 JavaScript 社区的狂热追捧，前端行业也因此进入了一个全新的工程化和全栈时代。回顾历史，总会让人心潮澎湃。在这股浪潮中，有无数的人和项目在这座丰碑中刻下了自己的名字：React、Vue、Yeoman、RequireJS、Backbone、Antd、Webpack、Mocha、Eslint 等等。在这些知名项目的熠熠光辉下，我们可能会忽略为 Node.js 生态的繁荣之下建立不世之功的 NPM，它才是当之无愧的肱骨重臣。

NPM 生于 2010 年 1 月，它从出生就背负了让 Node.js 社区更加繁荣的使命。NPM 致力于让 JS 程序员能够更加方便地发布、分享 Node.js 类库和源码，并且简化模块的安装、更新和卸载的体验。

从今天（2019 年）这个时间节点来看，NPM 无论从知名度、模块数量、社区的话题数量来看，都算得上是一骑绝尘，将其他语言的模块仓库远远甩在了后面。

数据来源: moudlecounts

NPM 的生态既已如此成熟，按说开发者对于 NPM 包的发布和维护应该非常熟悉才是，但事实真的是这样吗？环顾身边的 FE，没有发过任何 NPM 包的同学大有人在，已经发过包的同学也有相当一部分并未考虑过如何才算规范、高质量地发布一个包。

如今 NPM 的模块数量已上升至 100W，在这样一个 JavaScript 组件化开发时代，除了能找到好用的组件，我们自然也需要了解如何才能成为创造这个时代的一员。而第一步就是要知道并掌握如何规范地、负责任地发布一个 NPM 包？

这就是本文接下来的主要内容。

《蜕变》 | 2019 年"十一"，作者拍摄于雨岔峡谷。

一、组件化思考

发布人生中第一个 NPM 组件虽然只是在终端命令行中潇洒地敲下npm publish，静等成功通知即可，但这从 0 到 1 的跨越却并非易事。这个行为背后的始作俑者是开发者大脑中开始萌发组件化思维方式，开始去思考何为组件？为什么要发布组件？这些更深层次的问题。

组件的存在的终极意义是为了复用，一个组件只要具备了被复用的条件，并且开始被复用，那么它的价值才开始产生。组件复用的次数越高、被传播的越广，其价值就越大。而要实现组件的价值最大化，需要考虑以下几点：

1. 我要写一个什么组件？组件提供什么样的能力？
2. 组件的适用范围是什么？某个具体业务系统内还是整个团队、公司或者社区？
3. 组件的生产过程是否规范、健壮和值得信赖？
4. 组件如何被开发者发现和认识？

以上四点中，前两点是生产组件必须要思考的问题；第四点是组件如何推广运营的问题，这是另外一个话题，本文不展开探讨；第三点是开发者的基本素养，它决定了开发者如何看待这个组件，也间接暴露了开发者的素养和可信赖程度。

二、组件开发的最佳姿势

一个优秀的组件除了拥有解决问题的价值，还应该具备以下三个特点：

1. 生产和交付的规范性；
2. 优秀的质量和可靠性；
3. 较高的可用性。

只有三者都能满足才可以称其为优秀组件，否则会给使用者带来各种各样的困惑：经常出 Bug、坑很多、不稳定、文档太简单、不敢用等等。

2.1 规范性

2.1.1 目录结构

事实上，社区并没有一个官方的或者所有人都认同的目录结构规范，但从耳熟能详的知名项目中进行统计和分析，可以得出一个社区优秀开发者达成非官方共识的一个目录结构清单：

├─ test // 测试相关
├─ scripts // 自定义的脚本
├─ docs // 文档，通常文档较多，有多个 md 文档
├─ examples // 可以运行的示例代码
├─ packages // 要发布的 npm 包，一般用在一个仓库要发多个 npm 包的场景
├─ dist|build // 代码分发的目录
├─ src|lib // 源码目录
├─ bin // 命令行脚本入口文件
├─ website|site // 官方网站相关代码，譬如 antd、react
├─ benchmarks // 性能测试相关
├─ types|typings// typescript 的类型文件
├─ Readme.md // 仓库介绍或者组件文档
└─ index.js // 入口文件

以上目录清单是一个比较完整的清单，大多数组件只需根据自己的需求选择性地使用一部分即可。一份几乎适用于所有组件的最小目录结构清单如下：

├─ test // 测试相关
├─ src|lib //