0x00 前言

我想你一定没有真正通顺地读一遍本文的标题。

是的，这不重要。

大概只是扫了一眼，抓取到 插件、命令行 这样的关键字，所以你点开了这个链接。

不过我相信你一定是一个命令行开发的狂热分子，又或者只是对命令行开发有一点点感兴趣。

无论如何，我非常建议你花几分钟阅读完这一篇，然后我们可以通过其他的方式，继续讨论命令行开发的话题。

0x01 故事的起因: 我开发了太多的命令行工具

一开始只是因为懒（社会进步的动力），把一组经常要执行的命令，用Node开发成一个工具。

得益于Node出色的编程能力，以及丰富的file system API，它非常有效地把我们从繁琐的重复工作中解放出来。

在处理重复工作这件事上，计算机比人类可靠得多。 —— —— 某先哲

于是我们陷入了魔怔。

我们为本地开发流程规范开发了命令行工具。

我们为 持续集成/发布 过程开发了命令行工具。

我们为容器集群管理开发了命令行工具。

我们为我们见到的一切，开发了命令行工具。

渐渐地我们发现事情变得糟糕起来。

命令行工具让我们从重复工作里解放出来，却让我们陷入了重复的命令行开发当中。 —— —— 某先哲

0x10 插件，命令行需要插件

功劳最大的是 James， 他为我们准备了咖啡和小甜点，于是我们总结出目前的困境：

• 你不可避免地开发好几个独立的命令行工具

  如果我们把上面的几个工具集成到一起，那么它将变得非常臃肿。
  而且把一些不相干的命令全部放在一起，绝对不是个好主意。
  

• 我只想专注于我的命令在做什么，而不是一些重复的东西

  我们每开发一个新的工具，不得不做一些重复的内容，以便它看起来像一个完整的工具。
  因为我们要求它只管且漂亮。
  比如帮助信息、用例、格式化输出、参数定义、显示版本、升级。。。
  总之就是很多。
  

• 我很喜欢你做的这个功能，但是只能复制你的代码，这样看起来很蠢

  不仅如此。
  有时候，我甚至希望自己做出来这个功能，可以方便地分享给其他成员。
  

几乎没有任何分歧，我们认为接下来我们要做这样一个东西，它要实现这些特点：

1. 一个非常出色地完成帮助信息、用例、格式化输出、参数定义、显示版本等重复工作的命令行工具脚手架
2. 一个只关注命令行为逻辑的开发约定（你只需要写你的功能代码，而不是那些啰嗦的环节）
3. 命令必须是可以共享、替换、组合、进化的插件单元

平凡与伟大之间的距离，有时只是一杯咖啡。 —— —— 某先哲

0x11 正文开始：现在你可以使用一下 @mohism/cli-wrapper

如果你现在就去浏览 cli-wrapper文档 ， 并顺利开发出一个命令行工具，那这将是一个很好的开始。

因为对于 cli-wrapper 的定义：

• 首先它是一个脚手架，快速生成一个基础功能完善的项目，然后只写一点点你的创意

  cli-wrapper默默地为开发者提供了一系列我们过去开发命令行中被认为是good part的部分。开发者无需去学习怎样引导命令、怎样使用鲜明的输出信息、怎样存储本地文件、怎样去接收交互参数。

  你需要的仅仅是，弄清楚你要做的功能，然后写下为数不多的代码

• 其次，cli-wrapper开发的命令，都可以发布为插件

  这是一个令人兴奋的设计，我们之前的工具里有一些功能，是应该被共享到其他更多的工具里的， 比如 升级本程序、问题反馈。（截止到目前，你已经可以在npm上看到 升级本程序 ）

  而现在这一切变成现实。

  更可怕的是，我们把所有的命令都分别发布为插件，然后像乐高积木一样，任意组合出我们需要的命令行工具。

0x0д(overflow) 最后的最后

上面只是介绍了 cli-wrapper 这个项目的起源和一些粗浅的特性。

如果你是一个命令行开发爱好者，我强烈建议你

1. 移步 cli-wrapper文档 并尝试开发出一个命令行工具
2. 向 这个地方提出你宝贵的建议
3. 或者直接联系我们，交流一下命令行的开发心得。