bun

Fixes #44053 Problem A compiled binary resolves a bare specifier that is not embedded (left out with , or loaded with at runtime) from the process cwd only. With next to the binary and , it fails with . The cause is the standalone block in (). On a graph miss it substitutes the cwd as the source directory, so the walk in starts there. The executable's directory is never searched. Fix sets a one-shot (from , the path reports) for a bare specifier from a referrer. The source directory stays the cwd. checks in that one directory first, then walks from the cwd as before. runs once, after both, as before. The executable's parent directories are not searched. Order: embedded graph, next to the executable, cwd and its parents, . Relative specifiers, tsconfig paths, and self-references stay anchored on the cwd. A resolution that works on main changes only when exists. Verified: (4 new cases, 3 fail on main, 1 pins that parents are not searched), (1 new case that pins tsconfig paths to the cwd), plus all of both files, and . Cross-target passes. Background The issue proposed a flag and an order that puts before the cwd. This PR does neither: the case is a hard failure today, so a default search next to the binary breaks nothing, and the order is shared by every resolution. Considered walking the executable's parent directories too (the issue asked for it). A binary installed inside a global tree () then loads the global copy of a package before the project's copy, and the text compare that joins the two walks does not hold on Windows for a cwd reached through a junction or a short name. One directory has neither problem. Considered setting to (the mechanism). runs the loop after each root, so that gives exe, , cwd, : a reorder that changes which package wins for users who rely on today. Package.json loading stays off by default in compiled binaries. A package with or beside the binary needs (#28275). The docs section says so. Self-reviewed: 3 concerns raised, 2 addressed (keep the source directory at cwd, docs example needs the autoload flag), 1 rejected ( alternative, see above). Downsides A compiled binary reads one more directory per process on a bare-specifier miss: the executable's directory. Measured with the resolver's fs log: beside-exe layout 4 directory reads (fails) to 7 (works), cwd-only 6 to 7, nowhere 4 to 5. Later bare imports pay nothing (dir cache). Release binary text grows 768 bytes (, measured on the walking variant): +167, +402, new +190. Non-compiled callers pay one check per call and one branch per walk step. Interleaved A/B on release builds, 15 runs of 5000 calls: hit +0.5%, miss +10.1% with a 152% spread between base runs, so under the noise floor. , and are not available in this environment, so there is no instruction count. Notes Repro on 1.4.3: , copy and to , prints . With this PR it prints . Same for , with a referrer, and . still works from any layout. A package that is nowhere still fails with the same message. The cwd anchor came from #8023 (a crash fix). Before it a referrer was not absolute and fell into the generic cwd fallback, so cwd was never weighed against the executable's directory. A first draft replaced the source directory with the executable's directory. That moved tsconfig paths and lookups to the binary's location and broke when the binary lives outside the project. The autoload test fails on that draft and passes here. A second draft walked the executable's parents and then the cwd chain. Review found that a above both the binary and the cwd beat the cwd's own copy, and that a binary under a global tree picked up the global copies. fails on that draft and passes here. A compiled binary's embedded / of a bare package resolves from the cwd as before: its referrer is the cwd, not . Unchanged by this PR. from an embedded module keeps the caller's paths only ( set, no exe dir). Suites run: (89 pass; two unrelated plain tests hit the 5s local ceiling under the debug build in one run and pass alone), (24 pass), , (failures there are 5s timeouts under load, pass alone). no test proof · iteration 0 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/bundler/bundler_compile_autoload.test.ts, test/bundler/bundler_compile.test.ts no test proof · iteration 1 · platform-specific test(s) that do not run on this machine, deferring to CI, which covers all platforms: test/bundler/bundler_compile.test.ts

Problem aborts the process for an exported declaration with no initializer. with ends in `Option::unwrap()Noneexports.replaceexport let Areplace: { A: 1 }visit_declssrc/js_parser/visit/mod.rs:601replace_decl_and_possibly_removevisit_declmaintest/bundler/transpiler/transpiler.test.jssrc/exports.eliminateexports.replacevisit_decls::export let Aexport let Areplace: { A: 1 }export let A = 1;exports.texteliminate: ["A"]replace: { A: 1 }Segmentation fault at address 0x8mainOption::unwrap()Noneexport let A = 1;test/regression/issuemainexport let Aeliminate: ["A"]export let A, B = 1eliminate: ["A"]export let B = 1;export let Areplace: { A: 1 }export let A = 1;export let Areplace: { A: "bar" }export let A = "bar";export let Areplace: { A: ["N", "bar"] }export let N = "bar";export let A; A = 2;replace: { A: 1 }A = 2;export let A = 1;A = 2;namespace NS { export let A }replace: { A: 1 }var NS;((NS) => {})(NS = {});s_localvisit_decls::is_exportNS.A = 1exportsreplace with a string, after the load of another modulenew Bun.TranspilertransformSyncmain.textllvm-size -As_localnm -Ss_localexportsexportsmainmainvalgrindstraceperfmainexport class A {}eliminate: ["A"]panic: unreachablereplace: { A: ["default", 1] }`: #44138.

What version of Bun is running? 1.4.2, and 1.4.3-canary (the #44103 build, 47eeafc2c) What platform is your computer? Linux 7.2 x86_64 (WSL2), 16 vCPU What steps can reproduce the bug? shows the only threading-relevant difference between the SQLite in Node and the one in Bun (both , ): With memory statistics on, every SQLite and takes one process-wide mutex and updates shared counters. Connections are private to their threads, yet they all contend on that one lock. The SQLite docs recommend for this reason. This C program shows the cost on its own, with no Bun involved. 8 threads each open their own read-only connection and do point lookups that read all 21 columns, calling /// the way a JS binding does. The only change between runs is : memstat.c cc -O2 -o memstat memstat.c -lsqlite3 -lpthread ./memstat t.db 1 1; ./memstat t.db 8 1; ./memstat t.db 1 0; ./memstat t.db 8 0 ``node:sqlitebun:sqliteSELECT ... WHERE id = ?get()node:sqlitebun:sqliteperfbun-profileget()sqlite3Mallocsqlite3_freereleaseMemArraydb->mutexsqlite3_column_BUN_JSC_numberOfGCMarkers=1SQLITE_DEFAULT_MEMSTATUS=0sqlite3_config(SQLITE_CONFIG_MEMSTATUS, 0)` before SQLite initializes). I can't rebuild Bun to confirm the full effect, so treat the 25% as the C program's number, not Bun's.