这篇文章主要向大家介绍一个全局命令行辅助开发工具liftoff，这个工具在npm托管平台上周下载量还是很大的，但是在工作中却很少看见有人使用！目前我知道在使用它的构建工具有gulp和fis3！
liftoff的作用
1、全局命令行（npm install xxx -g）调用项目目录下安装的本地包（npm install xxx）
目前很多的构建工具都把自己的功能分成了两个部分：xxx-cli和xxx，比如gulp和webpack。
拿gulp举例，在安装完gulp-cli这个包后，是不能直接使用的，还需要在项目下安装gulp这个包才行，工具作者的想法就是gulp-cli负责命令行参数的处理，本地的gulp包才负责具体构建逻辑的处理，即gulp-cli会加载本地的gulp包，然后将命令行参数传给它！
一个全局命令行调用本地项目中安装的包还是比较麻烦的，好在liftoff提供了这个能力（内部使用的是resolve这个包完成这个工作）。
2、加载配置
你会发现gulp、fis3、webpack等等一些构建工具都有一个本地的配置文件xxx.config.js，显然在构建工具运行的时候需要读取这个配置，那么liftoff也提供了这个能力，它还处理了一些特殊的情况，比如配置文件在祖先目录下或者不在工程目录下等特殊情况！
3、编译特殊语言
有时用户在写配置文件时，不一定都会用javascript这个语言，如果用了其他语言开发了配置文件，node是无法加载的，所以需要先加载编译脚本使其先被编译，而liftoff就提供了这个能力，在使用特殊语言时可以先加载编译脚本！
liftoff的主要API
var Liftoff = require('liftoff'); //调用
var cli = new Liftoff(options);//实例化
cli.prepare(options, fn); //处理参数
cli.execute(options, fn); //执行回调函数
cli.launch(options, fn); //上面两个方法的组合
liftoff的使用详解
假设我们现在提前为百度写一个fis4（目前只有fis3），配置文件叫fis4-conf.js。
现在我们创建如下这样的目录：
图1
index.js是我们命令行的逻辑，本地开发可以先不发包，
fis4-conf.js是配置文件，
fis4-local是本地需要安装的包。
图2
如图2，在index.js中先实例化liftoff，传入的对象的属性在内部会被合并到cli这个实例对象上。这个配置中processTitle代表命令行运行后的进程名，moduleName代表这个命令行需要加载的本地的包名，configName代表本地配置的文件名！
如果上面三个属性都没传，只有name属性，processTitle和moduleName都会复用name的值，name再拼接一个‘file’字符串然后赋给configName。
extensions对象的key代表本地配置文件的后缀，value代表需要加载的编译脚本，值可以是null、字符串、数组等，内部会将extensions这个字段用fined这个包来解析，所以配置规则可以参考这个包！
图3
在图3中我们调用了prepare方法，require参数可以是数组也可以是字符串（包名），代表需要提前加载运行的包；cwd默认是进程运行的目录，这里通过cwd可以自定义root目录；configPath参数可以重新定义配置文件的路径。
现在我们打印一下后面回调函数的参数env，看看输出什么？
图4
如图4，liftoff帮我们找到了本地配置文件的位置和本地需要加载的包fis4-local的位置，说到这里我想大家应该明白了，这些信息既然都拿到了后面怎么运行就看你自己了。
我们再聊聊如何用其他语言开发配置文件比如ts
我们现在建一个ts配置文件fis4-conf.ts，如图5所示：
图5
图6
如图6所示，extensions后缀修改成ts，值变成需要提前加载的编译包，最后我们调用execute方法，这个方法不仅会加载extensions中注册的包，还会加载require中注册的包！
运行结果如下：
图7
很好，符合预期。
如果大家不太清楚自己使用的语言对应的编译脚本，可以使用interpret这个包，如下：
图8
图9
如图9所示，interpret已经为我们整理好了各种后缀对应的编译脚本的包！
总结
这篇文章主要分析了liftoff解决加载本地包、加载项目配置文件以及如何加载其他语言的编译脚本，可以把它当做我们开发命令行的辅助工具！另外既然我们了解了思路，其实我们也可以手写这些逻辑，不一定要复用它，造轮子才可以更快的成长！
喜欢我的文章就关注我吧，后续会更多干货输出，让我们一起学习，共同成长！（希望收藏之前大家关注一波-_-）