JavaScript 撰写自动化脚本的优点,看能不能劝服我们

先发于微信公众号前面从升阶到住院，请关注。

全文：thoughtspile.github.io/2022/02/14/…

前言

Vladimir 察觉自己一直反感 bash 整理的自动化流程脚本制作，而且在机缘巧合发觉同事都是有相近的念头，所以他分享在他看来 JavaScript 撰写自动化脚本的优点，看能不能劝服我们去共创更强生态。

与此相关的是，谷歌的 zx 新项目恰好是为此而生，而且在去年的 JavaScript 专用工具潮流趋势调研中获得了第一名。

在今年的最热门的项目谷歌的 zx，可以从 JavaScript 或 TypeScript 中撰写简单cmd脚本制作。

zx 适用在编码中置入一切 bash 关系式（ls、cat、git 这些），并借助 JavaScript 模版字面量得到结论。

zx 包括了好几个程序包所提供的作用：

node-fetch：使用与电脑浏览器中同样的 API 传出 HTTP 要求

fs-extra：运作文件目录

Globby：配对给出用户友好方式的文件夹名称

下面就是他所分享一些观点：

我还在日常工作中也感受到，大伙儿好像有的共识一般默认设置写自动化构建脚本制作时必须去用 bash，希望这篇文章能够带来大家一些不一样的思索，或许 JavaScript 去写会更好？

先看一下好多个很有可能的优势：

• 你团队可能会对 JS 最了解

• dev 和 CI 设备上很有可能默认设置装上 Node

• 就能直接浏览别的 JS 专用工具

• Node 是混合开发的运行中

• 进程间通信是多线程的，并且非常便捷

假如你时间有限得话，可以看看迅速较为报表：

是你团队关键语言表达

相较于 bash，大部分前端团队都那么了解 JS。Node 是有着特殊 API，但总体来说生活中有函数公式一等公民，循环系统和 promise 等了解特点。bash？我搞了几年来还是不要明确这是咋相关工作的 —— 词法很了解，但出乎意料的地区又不一样，大部分变量是字符串数组，究竟存有控制模块不？假如对不起，也别改正我，我不关心了。我一直仅仅使用的时候去谷歌搜索……

每一个体面地程序猿都要学习培训 bash？这也是心理扭曲的！假如你后面朋友必须从你的项目中做一些应急修改，那么他应当学习一些 JS。C 语言特点的词法让所有人都可以大致了解编码的用意。自然从这个角度来看 bash 应该差不多，但 JS 在这儿至少不比它差。

在 JS 优先选择团队中应用 JS 开展自动化脚本的撰写，是很有逻辑的挑选。

runtime 很有可能早已装上

你 bash 脚本制作即便取得成功运行了，不便也并没有结束，因为他往往会在另一台机器上不成功（说你呢，Alpine Docker 器皿……）。各种各样 shells（SH，ASH，BASH，ZSH）都有所不同，在不同 Linux 发行版上都不完整通用性。你完全可以手动式选择必须的包，或是再次笔写逻辑性，可是是真的很消耗时间。

用 Node 得话，遗失的 runtimes 问题十分罕见 - CI 设备不管怎样都能够运作 npm / yarn，这种和 node 绑在一起。除此之外，一旦 node 程序编程进行，一般每一台电脑中都能够运作。

开箱即用的平台特点

这便引出了下一点 —— node 是一个混合开发的运行中，在 linux、mac 和 windows 上运作优良。对，MacOS 是适配 POSIX 的，可是很多指令在选择项和输出格式上依旧有微小的差别。如今，我们需要 Windows 大力支持吗？尽管大部分前端工程师工作人员都采用 Mac，并且存有 Win 的 bash 端口号。可是，完全免费适用开箱即用总是非常好的：

• 减少了开源软件贡献阻碍。

• 一旦我们需要急匆匆在 Windows 服务器上运行 dev 云服务器情况下，一般都很不愉快的事。

• 主管想玩玩你新项目，但是他用的都是 Win 计算机。

Node 精英团队花掉了很多时间抽象化出电脑操作系统之间的差别。忽略这一点，而走坚持用 bash，会得不偿失。

直接访问别的 JS 专用工具

前端工作流（webpack/parcel/babel/PostSS）里的大部分专用工具都免费了 node APIs。乃至像 esbuild 和 swc 这种非 JS 专用工具也提供 node bindings。假如你自动化技术编辑在 node 上运作，那样浏览这种 API 就比较容易：仅需导进包并调用函数。

在 bash 中，有两种不便这个选项可以和根据 node 的一种手段集成化：

• 根据怪异这个选项文件格式启用 CLI。

• 撰写一个最小 JS 包装器来启用 node API，从 bash 启用它。

另外一个好处就是，因此许多工具的使用 CLI 坐落于独立的程序包中（如 @babel/CLI），假如直接用 node API，能够绕过组装，进而节约一点 npm i 时长。

体面地进程间通信

node 做为自动化技术运作时的一个非常棒的层面就是它的 IPC 水平。有时你最喜爱根据 CLI 而非 node API 使用其他专用工具。还可以 —— 在 node 中，这能通过 child_process 多线程且混合开发地做好！你甚至可以在不一样的进程中间应用管路导出，如同 shell 管道运算符 |。尽管内置的 Stream和child_process API 很有可能是不符合人体工学，但是你要根据自己的口感应用包装器——我特别喜欢execa。

bash 也擅于流程优化，但对我而言，有太多概率了——参照这一 stackoverflow 难题：里边提及有五种不同类型的并行处理运行指令的形式，如果你不知道自己在做什么，这便很容易使你玩火自焚自讨苦吃。

庞大生态体系

npm 为这样那样的问题提供了很好的解决方法。我最喜欢的是管理方法子进程的 execa、解决 CLI 选择项的yargs和输出款式的chalk。

没错，也存在相似的很多命令行工具，但必须采用特殊于操作系统的手机软件包管理器（apt？brew？apk？）组装他们。大家真的不想解决这类问题。除此之外，您安装一切 CLI 程序包还可以通过 spawn/exec 在 node 中应用。

因而，以下是我挑选 JS/node 来处理繁杂自动化工作流的重要原因：

• JS 就是你们团队关键语言表达！

• 连接点运行中一般组装在本地和 CI 中，因为你解决是指 npm/Spread。

• node 混合开发运作，与 bash 和 make 不一样。

• node 能够直接访问别的 JS 专用工具。

• node IPC（用以编辑 CLI 专用工具）完全没有问题，特别是应用 execa 时。

• 在 node 中撰写 CLI 专用工具，有许多好用的app包。

不过也有原因尽量使用 node（例如缺乏有关自动化技术用例的实例教程，针对不太熟悉 node 的人来讲，多线程的多元性），但我仍然相信这是 JS 工程中搭建自动化流程最有价值的挑选。

先发于微信公众号前面从升阶到住院，大量有意思的前面文章内容，请关注。