CLI实现前端构建自动化

全篇共 2289 字。按500字/分钟阅读,预计用时 4.6 分钟。总访问 644 次,日访问 2 次。

在上一篇《Github项目NPM依赖存在安全漏洞》文章中,我通过将项目的源代码和用于构建项目的代码分离。这解决了困扰我已久的问题——就是我的多个项目中,用于构建项目的代码相似,虽然每个项目单独拿出来既有源代码又包含构建环境,很完整,但是对我来说,要维护所有的项目,看起来就是重复的配置了,并且每个项目的NPM依赖都频繁地需要定期更新。

我把用于构建我所有项目的这些配置代码也当作一个项目维护了起来。问题总是接踵而至。虽然用于构建项目的配置代码分离了出来,但是我还得解决如何用一个项目来肩负起我的所有项目的构建工作。本篇我将在有多个前端项目的开发场景中创建交互提问式命令行,按需快速构建项目。

交互式命令快速选择并构建前端项目 - 陈帅华

受到别的提问式CLI工具的启发,我决定效仿搞起老。
上面GIF图就是我的构建项目的提问式CLI最终使用效果。
下面开始细说。

新的噩梦

我的上一篇文章《Github项目因NPM依赖包版本低存在安全漏洞》的解决方案是——将各个项目源代码与构建代码分离。如此高度集中式的管理构建代码的方式的前提一定是要建立在构建环境能满足各个项目各式各样的构建配置需求之上。不仅如此,集中式的项目构建形式还带来了一个等待我解决的问题,我想先试着解决的这一个痛点——如何在多个前端项目之间快速切换并完成项目的构建和目标代码的输出。

🤔️回想一下之前是如何切换前端项目的,就拿使用Webpack构建的项目们为例,我首先配置了一份项目清单,该配置清单罗列出所有需要用Webpack构建的项目的配置参数信息,然后将这一个个代表项目的配置对象放入数组中并导出给Webpack打包编译程序。导出的项目数组看起来是这样的:

module.exports = [
  {name: "project_01", config: {/*...*/}},
  {name: "project_02", config: {/*...*/}},
  {name: "project_03", config: {/*...*/}}
]

项目一般都是单独构建的,同时构建所有项目的情况不常见,不但构建速度降低而且会出现许多匪夷所思的问题。可是,如果现在我在做名为"project_01"的项目,"project_02"和"project_03"项目就不应该导出给Webpack打包编译程序,但是总不能把除"project_01"以外的项目都临时删掉,那就先将其他不在本次构建目标内的项目注释掉,配置清单现在看起来大概是这样的:

module.exports = [
  {name: "project_01", config: {/*...*/}},
  // {name: "project_02", config: {/*...*/}},
  // {name: "project_03", config: {/*...*/}}
]

🤷‍🤷‍♂️好吧!现在项目"project_01"整OK了。过了一会儿项目"project_02"也有一处需要优化。于是把除了项目"project_02"的其他项目都注释掉,只构建项目"project_02"。这当然可以算作一种解决方案。

也许还可以利用npm run命令,在package.json文件内的scripts对象上再配置和项目数一样多的看起来很相似的命令。执行不同的命令就构建不同的项目。这当然也可以算作一种解决方案。

交互式CLI工具

我倾向于让项目配置清单文件仅仅作为一个清单,只在增加新的项目或移除旧的项目时才去修改这份项目配置清单。而无需反复的注释,或者为每一个项目都重复创建一份配置清单文件。在需要更新项目时通过交互式命令选择要更新的项目并在选择完毕后自动开始构建项目。

由于项目的配置清单只有在增加和移除项目时才会修改,因此我将项目配置清单添加到package.json文件中,作为整个合集项目的配置文件的一部分使用。而scripts其实只需要一个命令即可——npm start

交互式命令行构建项目步骤

我发现,对于不稳定的配置项——比如当前要构建哪一个项目?——使用输出到哪里?——等等会频繁修改的配置项——就非常适合通过交互式命令的手段临时配置。问题很多且总是接踵而至,解决问题的方案也很多,结合实际情况而不盲目跟风总是明智的。

我使用 inquirer.js 为框架,完成了提问式CLI工具的开发。

成为全局命令

上面提到通过npm start命令启动构建项目的交互式命令行,这样就存在一个问题——我必须要进入存放构建代码的目录执行项目代码的构建。糟糕的开发场景是,我在project_01项目目录中完成源代码的书写,还要再跑到用于构建项目的目录中执行npm start命令。而理想的开发场景是,打开终端,不论在哪一个目录中都能立即执行构建项目的指令,大大提升效率。

构建代码目录结构及文件功能

将命令应用到全局。一种方法是发布NPM包,然后全局安装。另一种方法是npm link临时将未发布的本地NPM包直接安装到全局。我才用的是第三种方法,直接将开启交互式命令行的主文件连接到全局环境边上中,记得给文件加上执行权限,此时主文件成为可执行文件。我将软连接到全局环境的主文件重命名为q,相当于在全局释放一个名为q的变量,可以随处使用前端项目执行构建命令。

进入交互式命令行主文件软连接到全局环境变量内 - 陈帅华

原创作者 » 陈帅华
版权声明 » 自由转载-保持署名-非商用-非衍生
发布日期 » 2018年6月12日 周二
更新日期 » 2020年5月25日 周一
上一篇 » Github项目NPM依赖存在安全漏洞
下一篇 » 图解Gulp学习教程
:)记录此刻想法
请选择登录方式,开始记录你的想法。
授权微博登录
授权Github登录