这篇文章主要向大家介绍一个全局命令行辅助开发工具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。
现在我们创建如下这样的目录:
index.js是我们命令行的逻辑,本地开发可以先不发包,
fis4-conf.js是配置文件,
fis4-local是本地需要安装的包。
如图2,在index.js中先实例化liftoff,传入的对象的属性在内部会被合并到cli这个实例对象上。这个配置中processTitle代表命令行运行后的进程名,moduleName代表这个命令行需要加载的本地的包名,configName代表本地配置的文件名!
如果上面三个属性都没传,只有name属性,processTitle和moduleName都会复用name的值,name再拼接一个‘file’字符串然后赋给configName。
extensions对象的key代表本地配置文件的后缀,value代表需要加载的编译脚本,值可以是null、字符串、数组等,内部会将extensions这个字段用fined这个包来解析,所以配置规则可以参考这个包!
在图3中我们调用了prepare方法,require参数可以是数组也可以是字符串(包名),代表需要提前加载运行的包;cwd默认是进程运行的目录,这里通过cwd可以自定义root目录;configPath参数可以重新定义配置文件的路径。
现在我们打印一下后面回调函数的参数env,看看输出什么?
如图4,liftoff帮我们找到了本地配置文件的位置和本地需要加载的包fis4-local的位置,说到这里我想大家应该明白了,这些信息既然都拿到了后面怎么运行就看你自己了。
我们再聊聊如何用其他语言开发配置文件比如ts
我们现在建一个ts配置文件fis4-conf.ts,如图5所示:
如图6所示,extensions后缀修改成ts,值变成需要提前加载的编译包,最后我们调用execute方法,这个方法不仅会加载extensions中注册的包,还会加载require中注册的包!
运行结果如下:
很好,符合预期。
如果大家不太清楚自己使用的语言对应的编译脚本,可以使用interpret这个包,如下:
如图9所示,interpret已经为我们整理好了各种后缀对应的编译脚本的包!
总结
这篇文章主要分析了liftoff解决加载本地包、加载项目配置文件以及如何加载其他语言的编译脚本,可以把它当做我们开发命令行的辅助工具!另外既然我们了解了思路,其实我们也可以手写这些逻辑,不一定要复用它,造轮子才可以更快的成长!
喜欢我的文章就关注我吧,后续会更多干货输出,让我们一起学习,共同成长!(希望收藏之前大家关注一波-_-)