Bun

Bun v1.1.19


Dylan Conway · 2024 年 7 月 12 日

Bun v1.1.19 版本在此!此版本修正了 54 個錯誤(解決了 248 個 👍)。JavaScript 在 Windows 上變得更快。Raspberry Pi 4 支援回歸。.npmrc 中的 _auth 支援。bun install 保留 package.json 縮排。aws-cdk-lib 支援。修正了 new Response(request)fs.readdir 中的記憶體洩漏。多項可靠性改進。Windows 上靜態連結的 UCRT。

我們正在舊金山招聘系統工程師,以打造 JavaScript 的未來!

先前的版本

  • v1.1.18 修正了 55 個錯誤(解決了 493 個 👍)。支援 npmrc。改進了常數摺疊與 enum 內聯。改進了函式的 console.log 輸出。修正了工作區中修補依賴項的問題。修正了連結二進制檔案時 bun install 中的數個錯誤。修正了 dns.lookup 中的崩潰,並將 DNS 錯誤標準化以更好地匹配 Node。修正了 Bun.escapeHTML 中的斷言失敗。升級了 JavaScriptCore。
  • v1.1.17 修正了 4 個錯誤。修正了 bun repl 中的崩潰。使 macOS 上小型目錄的 fs.readdirSync 速度提高 5%。修正了 "ws" 模組未在 "send" 方法中呼叫回呼的問題。修正了在 bun install 中讀取損壞的 lockfile 時發生的崩潰。使 macOS 事件迴圈稍微快一些。
  • v1.1.0 Bundows。Windows 支援來了!

安裝 Bun

curl
npm
powershell
scoop
brew
docker
curl
curl -fsSL https://bun.dev.org.tw/install | bash
npm
npm install -g bun
powershell
powershell -c "irm bun.sh/install.ps1|iex"
scoop
scoop install bun
brew
brew tap oven-sh/bun
brew install bun
docker
docker pull oven/bun
docker run --rm --init --ulimit memlock=-1:-1 oven/bun

升級 Bun

bun upgrade

JavaScript 在 Windows 上變得更快

此版本在 Windows 上啟用了 WebKit 的 FTL JIT (Faster Than Light Just In Time Compiler,極速即時編譯器),從而提高了熱路徑效能。先前,此 JIT 僅在 macOS 和 Linux 上可用。

Object.entries 大約快了 20%

執行階段基準測試時間(平均)
Bun v1.1.19Object.entries(26 個鍵)726 奈秒/迭代
Bun v1.1.18Object.entries(26 個鍵)1'006 奈秒/迭代
Node v22.4.1Object.entries(26 個鍵)1'014 奈秒/迭代
Bun v1.1.19Object.entries(2 個鍵)55.99 奈秒/迭代
Bun v1.1.18Object.entries(2 個鍵)114 奈秒/迭代
Node v22.4.1Object.entries(2 個鍵)115 奈秒/迭代
Node v22.4.1Object.keys(26 個鍵)206 奈秒/迭代
Bun v1.1.19Object.keys(26 個鍵)509 奈秒/迭代
Bun v1.1.18Object.keys(26 個鍵)671 奈秒/迭代

Array.map 額外負擔降低約 50%

執行階段基準測試時間(平均)
Bun v1.1.19Array.map x 1 個參數31.23 奈秒/迭代
Bun v1.1.18Array.map x 1 個參數58.32 奈秒/迭代
Node v22.4.1Array.map x 1 個參數84.27 奈秒/迭代
Bun v1.1.19Array.map x 2 個參數30.42 奈秒/迭代
Bun v1.1.18Array.map x 2 個參數56.96 奈秒/迭代
Node v22.4.1Array.map x 2 個參數84.87 奈秒/迭代

還有更多。JavaScriptCore 的 FTL JIT 有 25,000 行 C++ 程式碼——它做了很多事。

===============================================================================
 Language            Files        Lines         Code     Comments       Blanks
===============================================================================
 C Header               46         4436         2407         1264          765
 C++                    35        29919        23306         1925         4688
===============================================================================
 Total                  81        34355        25713         3189         5453

非常感謝 @iangrunert

Raspberry Pi 4

Bun 再次支援 Raspberry Pi 4。已修正阻止 Bun 在 Raspberry Pi 4 上運行的建置問題。

Raspberry Pi 4

Linux 上減少 1 MB

我們啟用了連結時間最佳化,使 Linux 上的 Bun 減少 1 MB。

靜態連結的 Windows 建置

在 Windows 上,Bun 現在將使用靜態連結的 UCRT 副本。這表示您不需要安裝 Visual C++ 執行階段即可運行 Bun。

bun install 改進

bun install 尊重 package.json 縮排

現在使用 Bun 儲存新的依賴項時,package.json 中的空格和 Tab 縮排會被保留。

感謝 @dylan-conway

bun install 支援 .npmrc 中的 _auth

bun install 現在支援 .npmrc 檔案中的 _auth 選項。這對於同時提供使用者名稱和密碼很有用。

.npmrc
//https://127.0.0.1:4873/:_auth=${NPM_AUTH}

感謝 @zackradisic

已修正:選用同級依賴項導致的崩潰

在安裝選用同級依賴項期間,Bun 有時會崩潰。要重現此崩潰,需要此 package.json

package.json
{
    "dependencies": {
        "a": "1.0.0",
        "b": "1.0.0",
    }
}

以及這些依賴項

{
  "name": "a",
  "version": "1.0.0"
}
{
  "name": "b",
  "version": "1.0.0",
  "peerDependencies": {
    "a": "1.0.0"
  },
  "peerDependenciesMeta": {
    "a": {
      "optional": true
    }
  }
}

在運行 bun install、刪除 node_modules 和快取 (bun pm cache rm)、將 b 提升到更新版本(仍然對 a 有選用同級依賴項),然後使用現有 lockfile 再次運行 bun install 後,就會發生崩潰。

重現此崩潰需要幾個步驟,但對於像 vitevue 這樣的套件來說,這是一個常見問題,因為它們使用了選用同級依賴項。

現在已修正此問題,感謝 @dylan-conway

警告:當來自 bun install -g 的二進制檔案不在路徑中時

當全域 bin 資料夾不在路徑中時,Bun 現在將列印警告,並建議將該資料夾添加到路徑中。

bun add v1.1.19 (18a0f05c)

installed node-gyp@10.2.0 with binaries:
 - node-gyp

warn: To run "node-gyp", add the global bin folder to $PATH:

fish_add_path "/Users/jarred/.bun/bin"

已修正:Windows 上符號連結依賴項 postinstall 腳本的 cwd

在運行 postinstall 腳本之前,cwd 會設定為 node_modules 中的套件目錄。當套件是工作區時,node_modules 中的目錄是工作區的符號連結。在 posix 上,這沒問題——符號連結會被解析,並且 process.cwd() 會列印通過專案根目錄的絕對路徑。在 Windows 上,符號連結不會被解析,導致意外的 cwd 為 C:/path/to/proj/node_modules/workspace 而不是 C:/path/to/proj/workspace

現在,Bun 在 Windows 上手動解析這些路徑,以確保 cwd 是預期的路徑。

感謝 @dylan-conway

轉譯器改進

已改進:逗號表達式摺疊

Bun 在摺疊 JavaScript/TypeScript 中的逗號分隔表達式時不再使用遞迴,從而降低了堆疊溢出的風險。這修正了使用某些程式庫(如 aws-cdk-libaws-sdk)時發生的崩潰。

感謝 @paperclover

已修正:巢狀 TypeScript namespace 宣告的無效轉譯

已修正 TypeScript 轉譯錯誤,其中巢狀 namespace 被錯誤地轉譯,導致導出不可用。如果它們是非內聯命名空間,則可能會發生這種情況。

export namespace Foo.Bar {
  export function bar() {
    return "hello world";
  }
}

console.log(Foo.Bar.bar()); // "hello world"

感謝 @paperclover 修正了此問題!

可靠性改進

已修正:afterEach 回呼為 test.todo 運行

先前,afterEach 會為每個 test.todo 運行,導致以下程式碼失敗。現在已修正此問題。如果使用 --todotest.todo 將繼續觸發 afterEachbeforeEach

import { test, expect, afterEach } from "bun:test";

let count: number = 0;

afterEach(() => {
  count++;
});

test.todo("todo");

test("afterEach should not run for test.todo", () => {
  expect(count).toBe(0);
});

感謝 @ThatOneBro

已修正:new Request(request) 中的記憶體洩漏

當將 Request 實例傳遞給 Request 建構函式時,Request 建構函式會洩漏記憶體。現在已修正此問題。

const old = new Request("https://example.com", { body: "hello!" });

// This would leak memory:
const req = new Request(old);

這僅在將 Request 實例傳遞給 Request 建構函式時才會出現問題。將 Request 實例傳遞給 fetch 不受影響,傳遞形狀像 Request 實例的物件也不受影響。

已修正:使用 Bun.serve 發送大型檔案時崩潰

當使用 Bun.serve 發送大型檔案並且使用 process.kill 終止進程或中止請求時,Bun 有時會崩潰。感謝 @cirospaciari,此問題已修正!

已修正:使用 bun build 重新映射堆疊幀時崩潰

當使用 bun build --sourcemap=external --target=bun 時,字串上存在雙重釋放,導致分段錯誤。

感謝 @paperclover,此問題現已修正!

已修正:AbortSignal 使用 fetch() 的可靠性改進

當在 fetch() 中使用 AbortSignal 取消請求時,有時在響應完成後才會取消 HTTPS 請求。此錯誤現已修正。我們 BoringSSL 整合中的一個不正確選項導致其忽略 TCP 關閉呼叫。

感謝 @cirospaciari

已改進:來自 bun:jscprofile 現在支援 promise

在 Bun v1.1.19 中,您現在可以將 promise 傳遞給 profile

import { profile } from "bun:jsc";
const { promise, resolve } = Promise.withResolvers();
const result = await profile(
  async function test(input: string) {
    await Bun.sleep(10).then(() => resolve(input));
  },
  1,
  "input",
);
const input = await promise;
console.log(input); // { "0": "input" }

已修正:FormData.set 錯誤地設定檔案名稱

已修正 FormData 使用 .set 錯誤地設定檔案名稱的錯誤。感謝 @billywhizz,此程式碼現在將按預期工作!

using server = Bun.serve({
    port: 0,
    fetch: async req => {
        const data = await req.formData();
        const file = data.get("file");
        console.log(file.name); // foo.txt
        return new Response();
    }
})

const form = new FormData();
form.set("file", new File(["hello"], "foo.txt"));
await fetch(server.url, { method: "POST", body: form });

Node.js 相容性改進

fs 錯誤

此版本修正了 node:fs 中的參數驗證問題。

先前,以下程式碼會拋出令人困惑的錯誤

import { fs } from "fs";

fs.open("path");

先前的錯誤

bun-1.1.18.ts
1 | fs.open("path")
       ^
TypeError: path must be a string or TypedArray
 code: "ERR_INVALID_ARG_TYPE"

      at node:fs:36:26
      at open2 (node:fs:276:25)
      at path-to-file.ts:1:4

現在,錯誤正確地提及了缺少回呼

bun-1.1.19.ts
1 | fs.open("path")
       ^
TypeError: The "cb" argument must be of type function. Received undefined
 code: "ERR_INVALID_ARG_TYPE"

      at node:fs:2:30
      at open (node:fs:288:25)
      at path-to-file.ts:1:4

fs.write 參數修正

先前,以下輸入會錯誤地拋出錯誤

import fs from "fs";

fs.write(1, Buffer.from("hi"), 0, console.log, undefined);

現在它可以按預期工作,與 Node.js 一致。

先前,這會拋出有關缺少回呼的錯誤

1 | fs.write(1, Buffer.from("hi"), 0, console.log, undefined)
       ^
TypeError: Callback must be a function
 code: "ERR_INVALID_ARG_TYPE"
      at node:fs:2:30
      at write2 (node:fs:297:27)

已修正:fs.readdir withFileTypes: true 中的記憶體洩漏

當使用 withFileTypes: true 呼叫 fs.readdir 時,在讀取目錄條目時,path 屬性會洩漏記憶體。感謝 @billywhizz,此問題現已修正!

感謝 25 位貢獻者!