51工具盒子嗨！这周我一直在写一些 Javascript，和往常一样，当我开始一个新的前端项目时，我面临的问题是：我是否应该使用构建系统？
我想谈谈构建系统对我有什么吸引力，为什么我（通常）仍然不使用它们，以及一些前端 Javascript 库要求你使用构建系统时，为什么我觉得这让我感到沮丧。
我写这篇文章是因为我看到的大多数关于 JS 的文章都假定你正在使用构建系统，而对于像我这样的人来说，编写非常简单的、不需要构建系统的小型 Javascript 项目时，构建系统可能反而添加了很多麻烦。
什么是构建系统？ {#%E4%BB%80%E4%B9%88%E6%98%AF%E6%9E%84%E5%BB%BA%E7%B3%BB%E7%BB%9F}
构建系统的思路是，你有一堆 Javascript 或 Typescript 代码，你想在把它放到你的网站上之前把它翻译成不同的 Javascript 代码。
构建系统可以做很多有用的事情，比如：
- （出于效率的考虑）将 100 多个 JS 文件合并成一个大的捆绑文件
- 将 Typescript 翻译成 Javascript
- 对 Typescript 进行类型检查
- 精简化
- 添加 Polyfills 以支持旧的浏览器
- 编译 JSX
- 摇树优化Tree Shaking（删除不使用的 JS 代码以减少文件大小）
- 构建 CSS（像 tailwind 那样）
- 可能还有很多其他重要的事情
正因为如此，如果你今天正在构建一个复杂的前端项目，你可能会使用 Webpack、Rollup、Esbuild、Parcel 或 Vite 等构建系统。
很多这些功能对我很有吸引力，我过去使用构建系统也是出于这样一些原因： 例如，Mess With DNS 使用 Esbuild 来翻译 Typescript，并将许多文件合并成一个大文件。
目标：轻松地对旧的小网站进行修改 {#%E7%9B%AE%E6%A0%87%E8%BD%BB%E6%9D%BE%E5%9C%B0%E5%AF%B9%E6%97%A7%E7%9A%84%E5%B0%8F%E7%BD%91%E7%AB%99%E8%BF%9B%E8%A1%8C%E4%BF%AE%E6%94%B9}
我做了很多简单的小网站（之一、之二、之三、之四），我对它们的维护精力大约为 0，而且我改变它们的频率很低。
我的目标是，如果我有一个 3、5 年前做的网站，我希望能在 20 分钟内，
- 在一台新的电脑上从 GitHub 获取源代码
- 做一些修改
- 把它放到互联网上
但我对构建系统（不仅仅是 Javascript 构建系统！）的经验是，如果你有一个 5 年历史的网站，要重新构建这个网站会非常痛苦。
因为我的大多数网站都很小，所以使用构建系统的 优势 很小 ------ 我并不真的需要 Typescript 或 JSX。我只要有一个 400 行的 script.js 文件就可以了。
示例：尝试构建 SQL 实验场 {#%E7%A4%BA%E4%BE%8B%E5%B0%9D%E8%AF%95%E6%9E%84%E5%BB%BA-sql-%E5%AE%9E%E9%AA%8C%E5%9C%BA}
我的一个网站（SQL 试验场）使用了一个构建系统（它使用 Vue）。我最后一次编辑该项目是在 2 年前，是在另一台机器上。
让我们看看我今天是否还能在我的机器上轻松地构建它。首先，我们要运行 npm install。下面是我得到的输出：
$ npm install
[lots of output redacted]
npm ERR! code 1
npm ERR! path /Users/bork/work/sql-playground.wizardzines.com/node_modules/grpc
npm ERR! command failed
npm ERR! command sh /var/folders/3z/g3qrs9s96mg6r4dmzryjn3mm0000gn/T/install-b52c96ad.sh
npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/surface/init.o
npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/avl/avl.o
npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/backoff/backoff.o
npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_args.o
npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_stack.o
npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_stack_builder.o
npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channel_trace.o
npm ERR! CXX(target) Release/obj.target/grpc/deps/grpc/src/core/lib/channel/channelz.o
在构建 grpc 时出现了某种错误。没问题。反正我也不需要这个依赖关系，所以我可以花 5 分钟把它拆下来重建。现在我可以 npm install 了，一切正常。
现在让我们试着构建这个项目：
$ npm run build
? Building for production...Error: error:0308010C:digital envelope routines::unsupported
at new Hash (node:internal/crypto/hash:71:19)
at Object.createHash (node:crypto:130:10)
at module.exports (/Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/util/createHash.js:135:53)
at NormalModule._initBuildHash (/Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:414:16)
at handleParseError (/Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:467:10)
at /Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:499:5
at /Users/bork/work/sql-playground.wizardzines.com/node_modules/webpack/lib/NormalModule.js:356:12
at /Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:373:3
at iterateNormalLoaders (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:214:10)
at iterateNormalLoaders (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:221:10)
at /Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:236:3
at runSyncOrAsync (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:130:11)
at iterateNormalLoaders (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:232:2)
at Array.<anonymous> (/Users/bork/work/sql-playground.wizardzines.com/node_modules/loader-runner/lib/LoaderRunner.js:205:4)
at Storage.finished (/Users/bork/work/sql-playground.wizardzines.com/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:43:16)
at /Users/bork/work/sql-playground.wizardzines.com/node_modules/enhanced-resolve/lib/CachedInputFileSystem.js:79:9
这个 Stack Overflow 的答案 建议运行 export NODE_OPTIONS=--openssl-legacy-provider 来解决这个错误。
这很有效，最后我得以 npm run build 来构建这个项目。
这其实并不坏（我只需要删除一个依赖关系和传递一个略显神秘的 Node 选项！），但我宁愿不被那些构建错误破坏。
对我来说，对于小项目来说，构建系统并不值得 {#%E5%AF%B9%E6%88%91%E6%9D%A5%E8%AF%B4%E5%AF%B9%E4%BA%8E%E5%B0%8F%E9%A1%B9%E7%9B%AE%E6%9D%A5%E8%AF%B4%E6%9E%84%E5%BB%BA%E7%B3%BB%E7%BB%9F%E5%B9%B6%E4%B8%8D%E5%80%BC%E5%BE%97}
对我来说，一个复杂的 Javascript 构建系统对于 500 行的小项目来说似乎并不值得 ------ 它意味着放弃了在未来能够轻松更新项目的能力，以换取一些相当微小的好处。
Esbuild 似乎更稳定一些 {#esbuild-%E4%BC%BC%E4%B9%8E%E6%9B%B4%E7%A8%B3%E5%AE%9A%E4%B8%80%E4%BA%9B}
我想为 Esbuild 大声叫好： 我 在 2021 年了解到 Esbuild，并用于一个项目，到目前为止，它确实是一种更可靠的构建 JS 项目的方式。
我刚刚尝试在一台新电脑上构建一个我最后一次改动在 8 个月前的 Esbuild 项目，结果成功了。但我不能肯定的说，两年后我是否还能轻松的建立那个项目。也许会的，我希望如此！
不使用构建系统通常是很容易的 {#%E4%B8%8D%E4%BD%BF%E7%94%A8%E6%9E%84%E5%BB%BA%E7%B3%BB%E7%BB%9F%E9%80%9A%E5%B8%B8%E6%98%AF%E5%BE%88%E5%AE%B9%E6%98%93%E7%9A%84}
下面是 Nginx 实验场 代码中导入所有库的部分的样子：
<script src="js/vue.global.prod.js"></script>
<script src="codemirror-5.63.0/lib/codemirror.js"></script>
<script src="codemirror-5.63.0/mode/nginx/nginx.js"></script>
<script src="codemirror-5.63.0/mode/shell/shell.js"></script>
<script src="codemirror-5.63.0/mode/javascript/javascript.js"></script>
<link rel="stylesheet" href="codemirror-5.63.0/lib/codemirror.css">
<script src="script.js "></script>
这个项目也在使用 Vue，但它只是用 <script src 来加载 Vue ------ 前端没有构建过程。
一个使用 Vue 的无构建系统模板 {#%E4%B8%80%E4%B8%AA%E4%BD%BF%E7%94%A8-vue-%E7%9A%84%E6%97%A0%E6%9E%84%E5%BB%BA%E7%B3%BB%E7%BB%9F%E6%A8%A1%E6%9D%BF}
有几个人问如何在没有构建系统的情况下开始编写 Javascript。当然，如果你想的话，你可以写原味的 JS，但我常用的框架是 Vue 3。
这是我做的一个小模板，用于启动一个没有构建系统的 Vue 3 项目。它只有 2 个文件和大约 30 行的 HTML/JS。
有些库需要你使用构建系统 {#%E6%9C%89%E4%BA%9B%E5%BA%93%E9%9C%80%E8%A6%81%E4%BD%A0%E4%BD%BF%E7%94%A8%E6%9E%84%E5%BB%BA%E7%B3%BB%E7%BB%9F}
构建系统这些事情最近盘旋在我的脑海里，因为这周我正在用 CodeMirror 5 做一个新项目，我看到有一个新版本，CodeMirror 6。
所以我想 ------ 很酷，也许我应该使用 CodeMirror 6 而不是 CodeMirror 5。但是 ------ 似乎没有构建系统你就不能使用 CodeMirror 6（根据 迁移指南），所以我打算坚持使用 CodeMirror 5。
同样地，你以前可以把 Tailwind 作为一个巨大的 CSS 文件下载，但是 Tailwind 3 似乎根本不能作为一个大的 CSS 文件使用，你需要运行 Javascript 来构建它。所以我现在要继续使用 Tailwind 2。（我知道，我知道，你不应该使用大的 CSS 文件，但是它验收只有 300KB，而且我真的不希望有构建步骤）
（更正：看起来 Tailwind 在 2021 年发布了一个 独立的命令行工具，这似乎是一个不错的选择）
我不完全确定为什么有些库不提供无构建系统版本 ------ 也许发布无构建系统版本会给库增加很多额外的复杂性，而维护者认为这不值得。或者，库的设计意味着由于某种原因，不可能发布无构建系统版本。
我希望有更多的无构建系统的 Javascript 技巧 {#%E6%88%91%E5%B8%8C%E6%9C%9B%E6%9C%89%E6%9B%B4%E5%A4%9A%E7%9A%84%E6%97%A0%E6%9E%84%E5%BB%BA%E7%B3%BB%E7%BB%9F%E7%9A%84-javascript-%E6%8A%80%E5%B7%A7}
到目前为止，我的主要策略是：
- 在某个库的网站上搜索 "CDN"，找到一个单独的 Javascript 文件
- 使用 https://unpkg.com 来查看该库是否有一个我可以使用的内置版本
- 托管我自己的库的版本，而不是依赖可能崩溃的 CDN
- 编写我自己的简单集成方案，而不是拉入另一个依赖关系（例如，前几天我为 Vue 编写了自己的 CodeMirror 组件）。
- 如果我想要一个构建系统，就使用 Esbuild
还有一些看起来很有趣但我还没有研究过的东西：
- 这个 关于 Javascript 注释中类型语法的 Typescript 建议
- 一般来说，ES 模块
via: https://jvns.ca/blog/2023/02/16/writing-javascript-without-a-build-system/
作者：Julia Evans 选题：lkxed 译者：wxy 校对：wxy
