关于高产，不得不提到的一位就是 Sindre Sorhus 大神，截止到写这句话为止，Sindre Sorhus 一共在 npm 上发布了 1123 个包（你看我都不敢说“截止到写这篇文章为止”）, 在 Users Ranking - Gitstar Ranking 中可以看到用户获得star数量的排名，高居第一并且几乎是第二名的三倍，如下图：

什么？你说你没用他的包，那你真应该去翻翻你们公司项目的直接或间接依赖。在 Discover your ranking on GitHub 中可以看到 Discover your ranking on GitHub 关于 JavaScript 的排名，世界第13：

而排名高于他的前12位都是组织而非个人，所以他就是真正意义上的王者。

介绍了一位国外小哥之后，我再给大家介绍一位国内小哥，可以说接下来要介绍的这个人是我的精神领袖：EGOIST 。当然啦这是他的网名不是真实姓名，可能有的同学压根就没听过，也不奇怪，因为他在国外的知名度确实比在国内还高，上图：

看排名情况，JavaScript 在中国排第五，实际情况大家可以去看看，前四位中分别有两个组织和两个真人，这两个人分别是阮老湿和首席Markdown程序员。要是真论起创造和贡献，EGOIST 第二谁第一？当然了他本人不会这么说的，毕竟低调的很，不像我就会写写文章还骗不来流量。

感受到了别人的生产力之后，你有想过为什么吗？

之所以上面提到的两位被认可，不仅仅是他们高产似母猪，更重要的原因是：他们的作品在质量上是绝对“生产友好”的，换句话说他们的作品让别人觉得用起来靠谱，作品靠谱的本质是人靠谱。

人的因素我们不谈，我们来谈一下如何让作品变的靠谱。假设现在的你在看到上面两位之后早已变得热血沸腾，恨不得立马发个包到 npm，可惜你只是创建了一个 README 而已，却不知接下来该怎么做，没关系让我们一步一步来。

首先你要保证代码风格统一，并附以质量控制，这时候你开始找到 eslint / tslint 求助，经过你无数次的敲击键盘、安装依赖、翻查文档你终于搭建了一个你觉得还ok的架子。

接着你发现 prettier 对你来说是个好东西，于是你又经历了一次敲击键盘、安装依赖、翻查文档，不过好在你成功的把 prettier 集成到你的项目中了。

这还没完，你突然想要实现一个功能，你希望当文件被保存时自动 fix 代码风格，于是你找到了一个 vscode 插件，但你只想该插件作用域当前项目，于是你又开始了 敲击键盘、安装依赖、翻查文档......

接着你发现了新的问题，假如别的开发者没有使用用来格式化代码的vscode插件或者压根没用vscode的时候怎么办？这时别人是可以提交“脏”代码的，于是你开始希望在 commit 之前通过 git hook 能够完成自动格式化代码的工作，于是你转而求助于 husky 和 lint-staged 等工具，你再次经历敲击键盘、安装依赖、翻查文档。

好景不长，commit 这个关键词让你想起来另一个问题，那就是对于 commit msg 的校验，因为你想让你的项目变得专业，所以你希望你的所有 commit msg 都符合一定的规范，于是你开始想办法校验 commit 信息，不过好在你的无敌三连“敲击键盘、安装依赖、翻查文档”足够强大，你最终搞定了。

当你发现你的 commit 规范化了之后，你又产生了疑惑，既然 commit msg 已经规范了，那么如果能自动生成或以交互式的方式填写 commit msg 就更好了，于是你开始求助于 commitizen 和 cz-conventional-changelog 等工具，虽然此时你已经满头大汗，但你不想就此放弃你还是坚持着把他们集成到了你的项目中。

你擦了擦额头，当你冰凉的手背触碰到你额头的一刹那，你又产生了一个新的想法：咦，既然 commit msg 规范了，是不是可以通过 commit msg 自动生成 changelog 呢？于是你喝了一口咖啡，准备去拜访 conventional-changelog-cli 。

至此，你的项目在规范化和代码风格质量上的保证有了一定的起色，但是这就是优秀的项目了吗？不，这只是漂亮的外壳而已，优秀项目的内在一定是通过单元测试(或E2E，由于是纯js项目为主，所以不提E2E)保证的。于是你又开始了集成单测之路，在一开始你就遇到了一个小问题，你不知道使用哪个测试库好，经过你一些列的调查，你发现你最喜欢的两个测试库是 jest 和 ava ，但是不管选择哪个，你总是要集成进来，于是你又亮出了你的大招：无敌三连。

既然测试都已经集成了，那顺便生成测试覆盖率报告呗，在集成一下 CI 工具，你发现你的无敌三连虽然强大，但是天色已经见晚了，你家里的女朋友还在等你....，抱歉我忘记了你没有女朋友。

到了这里，一个项目的雏形就算是有了，不过你却忘记了一个直观重要的东西：编译。你的项目是准备为什么环境提供的？node 还是 web，环境的具体情况如何，你的代码是否需要编译，如果编译的话是用 rollup 还是 webpack？假设你开发的是纯 js 项目，并认为 rollup 更适合一些，你把 rollup 集成了进来。

经过一些列的战斗，你还是觉得差点什么，你开始纠结于 README 该怎么写，你开始查看各大开源项目的 README，企图借鉴，你开始到处收集 badges ，例如

。最后你拼装了一个还看得过去的内容，你终于认为你的项目及格了。突然，你收到的一条来自你女朋友的短信：“今晚不用回来了”，抱歉我又忘了你没有女朋友了......

虽然你没有女朋友或者你女朋友和你分手了，但是你还是很开心，因为你有一个及格的项目了，你在回家的路上忧喜参半。

第二天你思路爆棚，老子又有一个惊天地泣鬼神的项目了，那么大哥冷静一下，我问你个问题：“上面的那些流程你是准备重新走一遍，还是把第一个项目copy过去改一改？”。如果你重走一遍，恭喜你，你除了对工具的集成熟练度之外可能没什么提升，如果你copy修改的话，你却发现第一个项目除了那些基本内容之外还用了很多自己的依赖和工具，你苦于修改。

而且你是使用 jest 还是 ava 编写测试用例的代码是不太一样的，最重要的是，是否需要编译将影响你编写 jest 测试代码的方式，诸如此类细枝末节的东西，你要考虑很多。

咳咳，接下来就是广告时间，为了避免以上问题，我们可不可以开发一个模板，然后每次创建新项目的时候都使用这个模板以交互式的方式来初始化？当然可以，有的同学可能早就用过 Generators | Yeoman 了。但我这里给你们推荐我更喜欢的项目：saojs/sao 。

我编写了一个用于初始化项目的SAO Generator：sao-hcy-nm

每次当你新建项目的时候都可以使用命令 sao hcy-nm，你将会以交互式的方式来根据你的意愿创建新项目的模板，并具有本篇文章提到和没提到的所有特性，如下是一个截图：

支持如下特性：

• ✅ Respect the code style of prettier
• ✅ Automatically formatted when saving (You need to install the Prettier - Code formatter plugin)
• ✅ Automatic fix code style before commit (Thanks to husky and lint-staged)
• ✅ Check committed messages when committing
• ✅ Use yarn commit instead of git commit (Thanks to commitizen)
• ✅ Automatically generate changelog using yarn changelog (Thanks to conventional-changelog-cli)
• ✅ Automatic deployment with yarn release (Thanks to release-it)
• ✅ Optionally Unit test (jest or ava)
• ✅ Optionally test coverage
• ✅ Optionally compile ES2015 code using (Thanks to bili)
• ✅ Optionally add badge to README

现在，你的生活水平基本脱贫了，想要达到小康水平，那么还应该继续向 Sindre Sorhus 和 EGOIST 学习。

最后补充一点，HcySunYang/sao-hcy-nm 作为 saojs/sao 的生成器，其中使用到了用于编译的 bili ，并且 saojs/sao 和 bili 都是 EGOIST 的作品。回头我会和 EGOIST 要广告费的，手动微笑。