MagiCLI 简介:自动为任何模块生成命令行界面(CLI)

原文：https://medium.com/hackernoon/introducing-magicli-automagically-generates-a-command-line-interface-cli-for-any-module-49543e50f86d

MagiCLI 的目标是提供一种简单的方法来为任何模块生成命令行界面。这里的简单是指只需编写一行代码，就可以通过 CLI 使用任何模块。

要知道怎么做，你可以直接去魔法的储存库。要了解为什么我相信这能让我们所有人受益，继续阅读这篇文章。

众所周知，在 Node.js 开发人员中，package.json 文件可以包含一个名为 bin、的属性，该属性用于准备要通过 CLI 安装和执行的模块。如果你还不知道，我建议你在这里查看:https://docs.npmjs.com/files/package.json#bin

然后，我们有了一个简单的方法来创建一个专门从命令行使用的模块，随之而来的是向任何人提供一个选项，让他们从终端执行我们构建的模块，或者由运行在 Node.js 以外的环境中的程序通过子进程调用它。我想说的是，在很多时候，当我们想从终端做一些特定的事情时，我们很有可能在 npm 上找到一个能够做到这一点的模块，但是，它可能没有命令行界面。

目前，只有 11.86%发布的模块在 package.json 中定义了 bin 属性(我下载了注册表镜像来查找这个数字)。如果这些数字更高，在寻找通过命令行使用的程序/脚本时，我们会将 npm 作为一个来源。因此，我们会更频繁地使用 Node.js 来编写 CLI 工具(记住:一个源代码，一个 repo，一个跟踪问题和版本的地方，用于多平台)。当然，并不是每个发布在 npm 上的包都适合在终端上使用。现在很多前端的特定模块也在那里发布。但是，即使我们排除了这些类型的模块，我们仍然有数以千计的选择(并且还在增加)。

所以，如果 npm 已经给我们带来了一个简单的方法来为命令行准备一个模块，现在他们给我们带来了一个更简单和更好的工具来使用 CLI 模块，那就是 npx ，为什么我们不利用它呢？为什么我们不为自己建立一个庞大的 CLI 程序库呢？为什么通向#JavaScriptEverywhere 和#JSEverywhere 的道路还没有铺好？

原因是，尽管我们有办法做到这一点，但这不是免费的。它伴随着额外的努力，这是我们在接受它之前要考虑的。正如我们自然地对待其他事情一样，我们倾向于不投资(时间、精力、金钱等)。)在那里我们看不到回报。这将是创建一个 CLI 的成本，加上每次模块的 API 改变时维护它的成本。当一个模块最初不是被创建来通过命令行使用的，并且有人需要它并且最终会在 npm 上寻找它的机会非常低时，为什么要投资那些额外的步骤呢？

想到有人(甚至是我自己在未来的某个时候)可以从通过 CLI 使用我创建的一些模块的选项中受益，但当考虑到我提到的那些主题时，我停止了这样做，我开始看到如果可以毫不费力地创建并维护命令行界面以跟上模块 API 的变化，这对我们所有人来说将是多么好的事情。为了在这方面帮助我们， MagiCLI 在这里。

MagiCLI 分析模块导出的内容，并基于此创建帮助部分(针对每个命令)，基于函数参数名称定义预期选项，并为每个函数创建命令(包括嵌套属性)。它能够处理多种类型的模块导出，以及任何类型的函数参数声明(Rest 参数，析构)。支持异步方法(Promises ),还提供了一个简单的 API 来配置和处理执行流的一些步骤(stdin，before，after)。

请随意提出任何想法，以便改进该工具，同时，如果您发现您的案例出现了问题，也可以解决问题。GitHub 上还有另一个资源库， MagiCLI 测试机，在这里，许多真实发布的模块正在被成功测试。因为我们的想法是不断增加被测试的真实模块的数量，所以维护一个专门为此构建的存储库更有意义，而不是随着时间的推移不断增加 MagiCLI 本身的大小。如果您想为日益增多的测试做贡献，只需发送一个 pull 请求。

我只花了几分钟就把自己的一些模块更新成了 CLI，我希望 MagiCLI 也能帮助你；)