前端自动化构建工具-docker构建前端项目

我在日常工作中也意识到，大家似乎有一个共识，那就是在编写自动化构建脚本时应该默认使用bash。 希望这篇文章能给你带来一些不一样的思考。 也许用 JavaScript 编写更好？

让我们看看一些可能的优势：

如果你时间不够前端自动化构建工具，这里有一个快速比较表：

这是您团队的主要语言

大多数前端团队对 JS 的熟悉程度超过 bash。 Node 有一个特定的 API，但通常它具有熟悉的功能，如一流的函数、循环和承诺。 庆典？ 我已经研究了几年，但我仍然不确定它是如何工作的——语法很熟悉，但在意想不到的地方有所不同，大多数变量是字符串，是否存在模块？ 如果我错了，请不要纠正我，我不在乎了。 我总是在使用时去谷歌...

每个体面的程序员都需要学习 bash 吗？ 这有病！ 如果你的后端同事需要对你的项目做一些紧急的改动，他应该学点JS。 C 风格的语法让任何人都能大致了解代码的意图。 当然，从这一点来看，bash 也差不多，但至少 JS 在这里不比它差。

在以 JS 为先的团队中，使用 JS 进行自动化脚本编写是最合乎逻辑的选择。

运行时可能已经安装

即使你的 bash 脚本成功运行，麻烦也没有结束，因为它通常会在另一台机器上失败（比如你，Alpine Docker 容器......）。 各种 shell[3]（SH、ASH、BASH、ZSH）略有不同，并且在不同的 Linux 发行版中并不完全通用。 你当然可以手动挑选需要的包，或者手动重写逻辑，但这真的很浪费时间。

使用 Node，缺少运行时的问题非常罕见——CI 机器无论如何都可以运行 npm/yarn，它们与 node 捆绑在一起。 此外，一旦编写了节点程序，它通常会在每台计算机上运行。

开箱即用的跨平台功能

这就引出了下一点——node 是一个跨平台运行时，可以在 linux、mac 和 windows 上正常运行。 是的，MacOS 是 POSIX 兼容的，但许多命令在选项和输出格式上仍然存在细微差别。 现在，您需要 Windows 支持吗？ 虽然大多数前端开发人员使用 Mac，但存在用于 Win 的 bash 端口。 但是，开箱即用的免费支持总是很好：

Node 团队花费了大量时间来抽象化操作系统之间的差异。 忽略这一点并坚持使用 bash 会适得其反。

直接访问其他JS工具

前端工作流中的大多数工具（webpack/parcel/babel/PostSS）都公开节点 API。 甚至像 esbuild 和 swc 这样的非 JS 工具也提供节点绑定。 如果您的自动化编排在节点上运行，访问这些 API 很简单：只需导入包并调用函数。

在 bash 中，有两个麻烦的选项用于与基于节点的工具集成：

作为一个额外的好处，由于许多工具的 CLI 位于单独的包中（如 @babel/CLI ），如果您直接使用节点 API，则可以跳过安装并节省一点 npm i 时间。

体面的进程间通信

节点作为自动化运行时的一个很酷的方面是它的 IPC 功能。 有时您更喜欢通过 CLI 而不是节点 API 使用其他工具。 此外 - 在节点中前端自动化构建工具，这可以通过 child_process[4] 异步和跨平台完成！ 您甚至可以在不同进程之间通过管道输出，例如 shell 的管道运算符 |。 虽然内置的 Stream 和 child_process API 可能不太符合人体工程学，但您可以根据自己的喜好使用包装器——我更喜欢 execa。

bash 还擅长进程管理，但对我来说有太多的可能性——看这个 stackoverflow 问题：它提到了五种不同的并行运行命令的方式[5]，如果你不知道自己在做什么，那就是你很容易搬起石头砸自己的脚。

巨大的生态系统

npm 为各种各样的问题提供了很好的解决方案。 我最喜欢的是用于管理子进程的 execa[6]、用于处理 CLI 选项的 yargs[7] 和用于输出样式的 chalk[8]。

是的，同样存在许多命令行工具，但必须使用特定于操作系统的包管理器（apt？brew？apk？）安装它们。 人们真的不想处理这种问题。 此外，您安装的任何 CLI 包也可以通过 spawn/exec 在节点中使用。

所以，以下是我选择 JS/node 来管理复杂自动化工作流的主要原因：

当然避免使用 node 是有原因的（比如缺少自动化用例的教程，不熟悉 node 的异步复杂性），但我仍然相信它是 JS 项目中构建自动化流程的最可靠选择。

弗拉基米尔

参考文献[1]

弗拉基米尔：

[2]

zx:

[3]

各种贝壳：

[4]

子进程：

[5]

它提到有五种不同的方式并行运行命令：

[6]

执行：

[7]

雅格斯：

[8]

粉笔：