{% /raw %} ## Workspace packages can have npm version in dependencies now `bun install` now supports workspace packages in `dependencies` that specifies an npm version range to match against. {% codetabs %} ```json#packages/react-query/package.json { "name": "@tanstack/react-query", "version": "4.32.0", "dependencies": { "@tanstack/query-core": "^4.32.0" } } ``` ```json#packages/query-core/package.json { "name": "@tanstack/query-core", "version": "4.32.0", } ``` ```json#package.json { "name": "@tanstack/monorepo", "version": "4.32.0", "private": true, "workspaces": [ "packages/*" ], } ``` {% /codetabs %} This lets library authors have the same package.json for local development and publishing to npm. When the workspace member package in the local repository matches the npm version range, Bun will use the local workspace package. Otherwise, it will use the remote npm package. ## Improved support for private registries & Verdaccio Previously, Bun's http client would sometimes fail to connect to hostnames that worked in Node.js. This was caused by not passing the same options to `getaddrinfo` as Node.js does and by only checking the first address returned by `getaddrinfo` instead of all of them. This bug most often manifested as Bun being unable to connect to a private npm registry, since those are more often in a private network with interesting DNS configurations. [Verdaccio](https://verdaccio.org/) is a popular private npm proxy registry server and thanks to fixing this bug, you can use it as the registry for `bun install`. ## Bugfix for `/absolute/path/to/bun.lockb` Bun's lockfile is a binary format. To make it easier to inspect, Bun marks it as executable and you can run `./bun.lockb` to get a Yarn v1 style lockfile printed. However, there was a bug where passing an absolute path this way wouldn't work. This is now fixed. Before: ```sh $ /Users/jarred/Code/bun/bun.lockb lockfile not found: ``` After: ```sh $ /Users/jarred/Code/bun/bun.lockb # THIS IS AN AUTOGENERATED FILE. DO NOT EDIT THIS FILE DIRECTLY. # yarn lockfile v1 # bun ./bun.lockb --hash: BB257457B48409D5-2e33f90ba679b81f-4C68A5605FDDA532-9220e96d0851dbdf ... ``` ## Node.js compatiblity improvements We are hard at work on making Bun more compatible with Vite-powered frameworks. ### fs.watch reliability improvements @cirospaciari shipped several patches that improve the reliability and performance of `fs.watch`. - Previosuly, `vite dev` would spin up 11 threads to watch files. Now, it only needs 1 thread. - A crash when a permissions error occurred was fixed. - on macOS, a symlink to a directory would not always be watched. This is now fixed. - on macOS, the watcher would sometimes panic when watching a directory persistently. This has been fixed. - `fs.promises.watch` no longer causes the process to stay alive forever ### path.format bugfix A bug in `path.format` caused `vite build` to output `undefined` for css files. @paperclover fixed this in [#3734](https://github.com/oven-sh/bun/pull/3734/files) ### path.join latin1 encoding issue A bug in `path.join` when passed non-ascii latin1 strings could potentially return incorrectly encoded paths. ### path.dirname returned '.' for root paths `path.dirname` returned `'.'` for root paths, which caused some packages to not work with Bun. Thanks to [@Hanaasagi](https://github.com/Hanaasagi) for fixing this. ### StringDecoder toString latin1 bugfix The following code snippet produced different output in Bun and Node.js: ```js const { StringDecoder } = require("string_decoder"); const assert = require("assert"); const buf = Buffer.from("dd", "hex"); const sd = new StringDecoder("latin1"); const s = sd.write(buf); console.log(s); assert.strictEqual(s, "Ý"); ``` This was incorrect and has been fixed, thanks to [@Hanaasagi](https://github.com/Hanaasagi). ### fs.readdir() crash bugfix when returning a very large number of files Previously, `fs.readdir()` would crash when the number of strings was around 1000 or so. This bug was caused by incorrectly creating `Array` in native code, in a way that would cause garbage collection to free the array before it was returned to JavaScript. ### async fs.readdir(), fs.stat, fs.lstat, fs.readFile The following `node:fs` functions will now use Bun's thread pool to perform their work: Promises: - `fs.promises.readdir()` - `fs.promises.stat()` - `fs.promises.lstat()` - `fs.promises.readFile()` Callbacks: - `fs.readdir()` - `fs.stat()` - `fs.lstat()` - `fs.readFile()` Previously, Bun would make them return the expected values without actually performing the work on a separate thread. This helped improve the start time of `vite dev` a little. ### child_process.fork() is partially implemented `child_process.fork()` is partially implemented, thanks to [@sirenkovladd](https://github.com/sirenkovladd). IPC support is not implemented yet and will be added in a future release. ### stat() on large files Previously, `fs.stat()` on large files would truncate the extra signed integer bytes, returning incorrect values. This has been fixed. ```js import { statSync } from "fs"; // Before: statSync("./8gb-file.txt").size; // -635437056 // After: statSync("./8gb-file.txt").size; // 8589934592 ``` ### Missing final byte in fs.createReadStream() bugfix An off-by-one error caused some incorrect behavior in `fs.createReadStream()`. This has been fixed, thanks to [@Hanaasagi](https://github.com/Hanaasagi). This most frequently came up with the `compression` npm package when used with Express. ## Web Platform API compatiblity improvements Previously, Bun was not using WebKit's URL parser in `fetch()` and the HTTP client to parse & normalize URLs. This led to some incompatibilities and bugs. Bun now uses WebKit's URL parser in `fetch()` and the HTTP client. This also applies to `bun install`. ### `MessagePort` & `MessageChannel` are now supported The [`MessagePort`](https://developer.mozilla.org/en-US/docs/Web/API/MessagePort) and [`MessageChannel`](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel) APIs are new globals supported in Bun. Thanks to [@dylan-conway](https://github.com/dylan-conway) for getting this working, and for WebKit/Safari's team for the implementation. ```js const { port1, port2 } = new MessageChannel(); port1.onmessage = (e) => { console.log(e.data); // "hello!" }; port2.postMessage("hello!"); ``` One of the reasons why Bun bet on JavaScriptCore instead of embracing the server-side V8 monoculture is because JavaScriptCore and WebKit/Safari are strongly tied together. This means that Bun can often use implementations of Web APIs from WebKit/Safari directly, without having to reimplement them. This is a great example of that. ### fetch() supports file: URLs now You can now use `fetch()` to load files from the local filesystem. ```js const res = await fetch(new URL("hello!.jpg", import.meta.url)); await res.arrayBuffer(); ``` Internally, this is roughly equivalent to: ```js import { join } from "path"; const arrayBuffer = await Bun.file( join(import.meta.dir, "hello!.jpg"), ).arrayBuffer(); ``` ### Web Crypto API keeps the event loop alive now Previously, the following code would never log "finished": ```js crypto.subtle.digest("SHA-256", new Uint8Array([1, 2, 3])).then(() => { console.log("finished"); }); ``` Since the promise returned by `crypto.subtle.digest` was never awaited, Bun's event loop would exit before the Web Crypto API could finish its work. This bug has been fixed. Now the above code will log "finished" as expected. ## WebAssembly & Atomics bugfixes Bun's event loop will now wait for WebAssembly to finish loading before exiting the process. Previously, the following snippet would previously never log: ```js import Parser from "web-tree-sitter"; const main = async () => { console.log("start"); await Parser.init(); console.log("finished"); }; main(); ``` You had to `await main()`. Whether or not you prefer it to work this way, the status quo was a bug because other runtimes do not behave that way. This caused various packages wouldn't work. This bug impacted SolidStart, for example. A similar bug existed for `Atomics.wait()`. We made a small modification to JavaScriptCore to push tasks to our event loop. Of async work originating from JavaScriptCore, only WebAssembly and Atomics are affected. We do not wait for FinalizationRegistry to execute its callbacks before exiting the process (as FinalizationRegistry is not guranteed to be called to begin with). ## `Bun.isMainThread` and `Promise.withResolvers()` You can now use `Bun.isMainThread` to check if you are in the main thread. ```ts import { isMainThread } from "bun"; console.log("isMainThread", isMainThread); if (isMainThread) { const worker = new Worker(import.meta.url); const { promise, resolve } = Promise.withResolvers(); worker.addEventListener("open", () => { resolve(); }); await promise; } ``` You can also use `Promise.withResolvers()` to create a promise and its resolvers. This is a [TC39 stage3 proposal](https://github.com/tc39/proposal-promise-with-resolvers). ## expect(arg).pass() and expect(arg).fail() The jest-extended matcher `expect(arg).pass()` and `expect(arg).fail()` are now supported in `bun:test`, thanks to [@TiranexDev](https://github.com/TiranexDev). ```ts import { expect, test } from "bun"; test("expect().pass()", () => { expect(1).pass("I have passed!"); }); ``` ## Changelog [View the complete changelog](https://github.com/oven-sh/bun/compare/bun-v0.7.0...bun-v0.7.1)In the next version of Bun
— Jarred Sumner (@jarredsumner) July 24, 2023
bun:sqlite gets 10% faster at returning data pic.twitter.com/QUUxvMO9mv