为什么又造个轮子？

为什么又要构建一个 JavaScript 构建工具呢？因为当前用于 Web 的构建工具比用户期望的性能至少慢一个数量级。我希望这个项目可以作为一种“存在证明”，证明我们的 JavaScript 工具实际上能比现在快得多。

基准测试

我想到的用例是打包用于生产的大型代码库。这个流程包括压缩代码以减少网络传输时间，以及生成源映射（对于调试生产中的错误是非常重要的）。理想情况下，构建工具还应该具备快速构建能力，而不必先预热缓存。

我的主基准测试会将 three.js 库复制 10 次并从头开始构建单个包，过程中没有任何缓存，从而模拟一个大型代码库。在这个基准测试中，esbuild 比我测试的其他 JavaScript 打包器（Webpack、Rollup、Parcel 和 FuseBox）快 10-100 倍。这个基准测试可以使用’make bench-three’来运行。

时间数据取三次运行中最好的一次，主要运行环境如下：

使用’–bundle --minify --sourcemap’来运行 esbuild。
使用’rollup-plugin-terser’插件，因为 rollup 自身不支持压缩。
Webpack 使用的是’–mode = production --devtool = sourcemap’。
Parcel 使用默认选项。
FuseBox 使用’useSingleBundle: true’配置。
绝对速度基于总行数（包括注释和空白行），当前为 547,441。
测试是在配备 16GB RAM 的 6 核 2019 MacBook Pro 上完成的。

为什么这么快？

几个原因：

它是用 Go 语言编写的，该语言可以编译为原生代码；
解析，打印和源映射生成全部完全并行化；
无需昂贵的数据转换，只需很少的几步即可完成所有操作；
编写代码时处处注意速度表现，并尽量避免不必要的配置。

状态

目前支持：

CommonJS 模块
ES6 模块
使用’–bundle’与 ES6 模块的静态绑定打包
使用’–minify’完全压缩（空格、标识符和修饰符）
启用’–sourcemap’时，完全支持源映射
.jsx 文件的 JSX 到 JavaScript 转换
通过’–define’进行编译时标识符替换
使用 package.json 中的’browser’字段进行路径替换
自动检测 tsconfig.json 中的’baseUrl’

这是我在 2019-2020 年寒假期间写的一项业余爱好项目。我相信它是相对完整和实用的。但它是全新的代码，可能有很多错误。还没有任何人在生产中使用过它。使用风险自负。

还请记住，它并不完全支持将现代语言语法降低到早期语言版本。目前只有类字段和 nullish 合并运算符是支持的。

我个人不想运营一个大型的开源项目，因此我目前没在寻求贡献。

安装

如果你已安装 Go 语言工具链，可以使用’make’生成可执行文件。当前可在 npm 上的单独软件包中找到预构建的二进制文件：

npm install -g esbuild-linux-64   # for Linux
npm install -g esbuild-darwin-64  # for macOS
npm install -g esbuild-windows-64 # for Windows
npm install -g esbuild-wasm       # for all other platforms

这将添加一个名为’esbuild’的命令。

用法

命令行界面获取入口点列表，并为每个入口点生成一个打包文件。以下是可用的选项：

Usage:
  esbuild [options] [entry points]

Options:
  --name=...            模块名称
  --bundle               将所以依赖项打包进输出文件
  --outfile=...         输出文件 (用于一个入口点)
  --outdir=...          输出目录 (用于多个入口点)
  --sourcemap            发出一个源映射
  --error-limit=...     最大错误计数，0是禁用 (默认值为10)
  --target=...          语言目标 (默认esnext)

  --minify              设置所有 --minify-* flags
  --minify-whitespace   移除空格
  --minify-identifiers  缩短标识符
  --minify-syntax       使用较短的等效语法

  --define:K=V          解析时用V替换K
  --jsx-factory=...     用来替换React.createElement的内容
  --jsx-fragment=...    用来替换React.Fragment的内容

  --trace=...           在这个文件中写入一个CPU trace
  --cpuprofile=...     在这个文件中写入一个CPU profile

Example:
  # Produces dist/entry_point.js and dist/entry_point.js.map
  esbuild --bundle entry_point.js --outdir=dist --minify --sourcemap

与 React 一起使用

要将 esbuild 与 React 一起使用：

确保所有JSX语法都放在.jsx文件而不是.js文件中，因为esbuild使用文件扩展名来确定要解析的语法。
如果你使用的是TypeScript，请先运行’tsc’以将.tsx文件转换为.jsx或.js文件。
如果你使用esbuild打包React自身，而不是在HTML中使用<script>标记添加它，则需要传递 ‘–define:process.env.NODE_ENV=“development”’ 或’–define:process.env.NODE_ENV=“production”'以在命令行上运行esbuild。
如果你使用的是Preact而不是React，则还需要传递–jsx-factory = preact.h --jsx-fragment = preact.Fragment在命令行上运行esbuild。

例如，如果你有一个名为 example.jsx 的文件，其中包含以下内容：

import * as React from 'react'
import * as ReactDOM from 'react-dom'

ReactDOM.render(
  <h1>Hello, world!</h1>,
  document.getElementById('root')
);

那么用于开发构建：

esbuild example.jsx --bundle '--define:process.env.NODE_ENV="development"' --outfile=out.js

用于生产构建：

esbuild example.jsx --bundle '--define:process.env.NODE_ENV="production"' --minify --outfile=out.js

项目地址

https://github.com/evanw/esbuild

创作场景

esbuild：一款快 10-100 倍的 JS 打包 / 压缩工具