Bun 是一款集 JavaScript 运行时、打包器、转译器和包管理器于一体的超快软件。

Bun v1.1.7 版本发布！这个版本修复了28个bug（解决了11个）。在 bun install 中增加了对 Glob 工作区名称的支持。在 expect.extends() equals 中增加了对不对称匹配器的支持。新增了 bunx --version。修复了 JSX 转换、源代码映射、独立可执行文件的交叉编译、bun shell、RegExp、Windows 上的 Worker 以及 Node.js 兼容性的改进。

我们正在旧金山招聘系统工程师，共同塑造 JavaScript 的未来！

早期版本

v1.1.6 修复了 10 个 bug（获得 512 个反应）。我们实现了 UDP 套接字支持和 node:dgram。DataDog 和 ClickHouseDB 现在可用。我们还修复了从 v1.1.5 开始的 node:http 回归问题。同时也有 Node.js 兼容性的改进和 bug 修复。v1.1.5 修复了 64 个 bug（获得 101 个）。bun build --compile 跨平台编译独立的 JavaScript 和 TypeScript 可执行文件。通过 type: "text" 导入属性，以文本形式导入任何文件。引入新的崩溃报告器。package.json 在有注释或尾随逗号的情况下不会报错。修复了 bun run --filter 退出时返回 0 的 bug。修复了 bun install 中 file: 依赖的 bug。修复了 node:fs、node:tls、node:crypto、node:readline、node:http、node:worker_threads 中的 bugv1.1.0 Bundows。现在支持 Windows！

安装Bun：

# curlcurl -fsSL https://bun.sh/install | bash# npmnpm install -g bun# powershellpowershell -c "irm bun.sh/install.ps1|iex"# scoopscoop install bun# brewbrew tap oven-sh/bunbrew install bun# dockerdocker pull oven/bundocker run --rm --init --ulimit memlock=-1:-1 oven/bun

升级Bun：

bun upgrade在 bun install 中使用 Glob 匹配工作区名称

现在你可以在`package.json`文件中的工作区中使用高级的glob模式来指定要在单仓库中包含哪些目录。例如：

{ "name": "monorepo", "workspaces": ["{app,packages,lib}/**"]}

之前，我们只支持将 /* 作为工作区中的模式或确切路径。现在，工作区匹配由 Bun.Glob 提供支持，因此您可以使用 Bun.Glob 支持的任何 glob 模式。

expect.extends() 中的不对称匹配器支持

现在，您可以在 expect.extends() equals 中使用 this.equals 时使用非对称匹配器。例如：

import { test, expect } from "bun:test";expect.extend({ toCustomEqual(actual, expected) { return { pass: this.equals(actual, expected) }; },});test("asymmetric matchers", () => { expect(1).toCustomEqual(expect.anything()); expect(1).toCustomEqual(expect.any(Number));});

之前这会引发一个错误。现在，它按照预期运行。

bunx --version

当你运行bunx --version时，Bun现在会打印出版本号：

bunx --version# 1.1.7

以前，bunx --version 会打印帮助菜单：

$ bunx --versionUsage: bunx [...flags] <package>[@version] [...flags and arguments]Execute an npm package executable (CLI), automatically installing into a global shared cache if not installed in node_modules.Flags: --bun Force the command to run with Bun instead of Node.jsExamples: bunx prisma migrate bunx prettier foo.js bunx --bun vite dev foo.jsWebSocket 关闭代码 1015

当一个 WebSocket 客户端连接因 TLS 错误而无法连接时，现在的关闭代码是 1015 而不是 1006。这更加准确，有助于调试。

const ws = new WebSocket("wss://localhost:3000");ws.on("close", ({ code, reason }) => { console.log(code); // 1015 console.log(reason); // "TLS handshake failed"});

之前，关闭码是1006，它是一个通用错误码。

未处理的错误现在将打印Bun版本

当抛出顶层错误或拒绝 Promise 时，Bun 现在会在末尾打印 Bun 版本：

1 | function hi() {2 | return 42;3 | }4 |5 | function yo() {6 | throw new Error("uh oh!"); ^error: uh oh! at yo (error.js:6:9) at hey (error.js:11:3) at error.js:14:1Bun v1.1.7 (macOS arm64)

这在请求他人调试帮助时很有用，因为它可以节省一个问题：“你正在使用Bun的哪个版本？”

已修复：在Bun Shell中使用seq、basename、dirname时，空输出会导致程序挂起

在Bun Shell中，当seq、basename或dirname被调用且输出为空时，由于未关闭输出流，它们会无限期地挂起。这个问题已在Bun v1.1.7中得到修复，感谢@RanoIP的贡献。

已修复：Windows 启动时可能发生的崩溃问题

Zig标准库函数std.mem.indexOfScalarPos中的SIMD代码路径的无效内存访问可能导致Windows上的Bun在初始化期间立即崩溃。这个问题在Bun v1.1.7中已得到修复。

此外，我们还为搜索指针中的哨兵值的代码添加了一个优化，以便在适当的时候使用Windows wcslen和strlen函数，而不是较慢的手动实现。

已修复：进程生成后可能出现的崩溃

在Bun v1.1.7中，已经修复了一个崩溃问题，该问题有时发生在子进程在stdin流被收集之前被垃圾收集时。

已修复：退出时发生崩溃，涉及 Worker

在Bun v1.1.7中，已修复了当Worker仍在运行时Bun退出时可能出现的崩溃问题。这种崩溃是由于在std::quick_exit期间为每个线程运行threadlocal析构函数而引起的。

已修复：在Windows上读取目录时崩溃

在Windows上读取目录时，Bun假设NT API中的FILE_DIRECTORY_INFORMATION结构体根据Windows API文档进行了8字节对齐。但是，运行时的安全检查证明这是错误的。我们已经在代码中放宽了对该结构体的对齐要求，因此这个崩溃应该不会再发生了。

已修复：Windows 上内存不足时的崩溃问题

当mimalloc内存分配器因内存不足而返回NULL时，Bun会因断言失败（如mimalloc：分配的大小太小）而崩溃。这种断言失败仅用于开发和测试，而不适用于发布版本（尽管我们在Windows上默认启用断言）。

这个问题已在Bun v1.1.7中得到修复。

当系统内存非常低或模拟低内存时，将大文件上传到Bun.serve()服务器时，这个问题最容易重现。

已修复：当 WebSocket 客户端在 Windows 上出现连接错误时崩溃

在 Windows 上，当 WebSocket 客户端连接无法连接时，可能会发生崩溃现象，现已修复此问题。我们增加了一项测试，以防止在未来出现回归现象。

已修复：UDP套接字现在会在有效的端口号上抛出异常

在Bun v1.1.6（之前的版本）中，我们为UDP套接字支持引入了Bun.udpSocket。

之前，所有不在1到65535之间的端口号都将被视为0，并使用随机分配的端口。现在，如果提供的端口号无效，Bun.udpSocket将抛出错误。

已修复：带有错误行号的堆栈跟踪

在Bun v1.1.7中修复了一个导致堆栈跟踪有时显示错误行号的错误（注意：可能还有其他错误导致此问题）。

这个错误是由C++代码中的一个未初始化的整数引起的。我们正在将clang-analyzer添加到Bun的CI中，以防止这种情况再次发生。

已修复：sourcemap回归导致bun构建挂起

在Bun v1.1.6中引入的一个sourcemap回归导致bun构建无限期地挂起。这已在Bun v1.1.7中修复，并且我们添加了一个集成测试来防止未来再次出现回归。

例如，对这样一个“hello world”express.js应用使用bun build --sourcemap=external会导致挂起：

const express = require("express");const app = express();const port = 3000;app.get("/", (req, res) => { res.send("Hello World!");});app.listen(port, () => { console.log(`Example app listening on port ${port}`);});

我们增加了一个集成测试，以确保 bun build --compile --minify 的输出能够成功运行一个简单的 express.js 应用。

已修复：可执行文件的跨平台编译到Windows或从Windows跨平台编译

在跨平台编译<>Windows中，我们假设如果当前平台是Windows或posix，就会使用该平台的文件路径前缀，而不是跨平台编译目标的平台。这个错误已经修复。

已修复：未读服务器端请求体的内存泄漏回归问题

在Bun v1.0.30 - Bun v1.1.6中，Bun.serve()中的未读入的HTTP请求体没有被正确清理。这也适用于node:http服务器。

这意味着选择不读取传入请求的主体可能会导致内存无限期地消耗。这个问题在Bun v1.1.7中得到了修复，我们还添加了回归测试以防止这种情况再次发生。

已修复：fs.fdatasync 中缺少 fd 在错误中

当在 fs.fdatasync 中抛出错误时，错误对象中缺少 fd 属性。这个问题在 Bun v1.1.7 中已经修复。

已修复：自定义检查异常

当自定义检查函数抛出异常时，Bun 会返回 [native code]。这让人困惑。我们希望能将其更改为抛出错误，但这将是一个重大更改。相反，我们将其更改为打印 [custom formatter threw an exception]，这稍微好一些，但还不是我们更希望的方式。在 Bun 的未来版本中，我们将更改此行为以抛出错误，但我们不希望您的代码在次要版本更新中随机崩溃。

ServerWebSocket 微优化

Zig 中 ServerWebSocket 表示的内存大小已从 32 字节缩小到 24 字节。您可能不会注意到内存节省，但由于更好的缓存局部性，它可能会使某些函数运行得更快。