refactor: replace Bun APIs with Node.js equivalents

[BYK]

Summary

Third step of the Bun → Node.js migration (follows #967, #970). Replaces all Bun-specific API calls in src/ with Node.js equivalents.

Changes

File I/O (18 files):

• Bun.file(path).text() → readFile(path, "utf-8") from node:fs/promises
• Bun.file(path).json() → JSON.parse(await readFile(path, "utf-8"))
• Bun.file(path).exists() → access(path).then(() => true, () => false)
• Bun.file(path).stat() → stat(path) from node:fs/promises
• Bun.write(path, content) → writeFile(path, content) from node:fs/promises
• Bun.write(dest, Bun.file(src)) → copyFile(src, dest) from node:fs/promises

Process/System (9 files + 1 new):

• Bun.which() → new src/lib/which.ts helper using command -v (POSIX) / where (Windows)
• Bun.spawn() → spawn() from node:child_process with Promise-wrapped exit code
• Bun.spawnSync() → spawnSync() from node:child_process
• Bun.sleep() → setTimeout() from node:timers/promises

Utilities (6 files):

• Bun.Glob → picomatch (already a devDependency)
• Bun.randomUUIDv7() → uuidv7() from uuidv7 package
• Bun.semver.order() → compare() from semver package

What's NOT in this PR (Group D — separate follow-up)

These Bun APIs in bspatch.ts and upgrade.ts require more careful handling:

• Bun.file().writer() — streaming file writer (needs fs.createWriteStream)
• Bun.zstdCompress/DecompressSync — zstd compression (needs node:zlib 22.15+)
• Bun.mmap() — memory-mapped files (has existing fallback)
• Bun.CryptoHasher — streaming hash (needs crypto.createHash)

Test results

All 7012 unit tests pass, 0 failures.

[github-actions]

PR Preview Action v1.8.1
🚀 View preview at https://cli.sentry.dev/_preview/pr-984/
Built to branch gh-pages at 2026-05-20 14:58 UTC. Preview will be ready when the GitHub Pages deployment is complete.

[cursor]

Cursor Bugbot has reviewed your changes and found 3 potential issues.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 98702ba. Configure here.}

[cursor]

Spawn errors silently swallowed, breaking retry logic

High Severity

In Node.js, child_process.spawn emits ENOENT and EBUSY as asynchronous 'error' events rather than throwing synchronously (unlike Bun.spawn). The proc.on("error", () => resolve(1)) handler silently resolves the promise with exit code 1, so the catch block's ENOENT-to-UpgradeError translation and EBUSY retry-with-backoff logic are now unreachable dead code. The function will return 1 instead of retrying on Windows antivirus locks or showing a user-friendly message for missing binaries. The error handler needs to reject instead of resolve so the catch block can inspect the error.

 

^{Reviewed by Cursor Bugbot for commit 98702ba. Configure here.}

[github-actions]

Codecov Results 📊

✅ 7012 passed | Total: 7012 | Pass Rate: 100% | Execution Time: 0ms

📊 Comparison with Base Branch

Metric	Change
Total Tests	—
Passed Tests	—
Failed Tests	—
Skipped Tests	—

✨ No test changes detected

All tests are passing successfully.

❌ Patch coverage is 78.19%. Project has 14194 uncovered lines.
✅ Project coverage is 77.13%. Comparing base (base) to head (head).

Files with missing lines (8)

File	Patch %	Lines
src/lib/clipboard.ts	11.76%	⚠️ 15 Missing
src/lib/which.ts	63.41%	⚠️ 15 Missing
src/lib/browser.ts	69.23%	⚠️ 4 Missing
src/commands/dashboard/list.ts	60.00%	⚠️ 2 Missing
src/lib/shell.ts	88.24%	⚠️ 2 Missing
src/commands/cli/upgrade.ts	88.89%	⚠️ 1 Missing
src/lib/init/tools/run-commands.ts	90.91%	⚠️ 1 Missing
src/lib/scan/grep.ts	50.00%	⚠️ 1 Missing

Coverage diff

@@            Coverage Diff             @@
##          main       #PR       +/-##
==========================================
+ Coverage    77.12%    77.13%    +0.01%
==========================================
  Files          321       322        +1
  Lines        61993     62061       +68
  Branches         0         0         —
==========================================
+ Hits         47808     47867       +59
- Misses       14185     14194        +9
- Partials         0         0         —

---

Generated by Codecov Action

[sentry-warden]

Node.js spawn errors swallowed in Promise, making EBUSY retry and ENOENT detection dead code

Unlike Bun.spawn(), Node.js child_process.spawn() never throws synchronously — ENOENT and EBUSY are delivered as error events on the child process. The proc.on("error", () => resolve(1)) handler silently resolves with exit code 1, so the catch block (with its ENOENT→UpgradeError translation and EBUSY retry loop) is unreachable dead code. Change the error handler to reject(err) so errors propagate into the catch block.

Evidence

• spawn from node:child_process (imported at line 17) returns a ChildProcess immediately without throwing; errors arrive via proc.on('error', …), not as exceptions from the spawn() call itself.
• spawnWithRetry (line 423) wraps spawn in a try/catch that expects synchronous throws — valid for Bun.spawn() but not for Node.js.
• proc.on('error', () => resolve(1)) at line 436 converts every spawn error (ENOENT, EBUSY, EACCES) into a successful promise resolution with exit code 1, bypassing the catch block entirely.
• The EBUSY retry loop (lines 453–460) — the stated purpose of the function and specifically needed for Windows Defender scanning — therefore never executes.
• The ENOENT→UpgradeError('execution_failed') path (lines 448–453) also never executes, losing the actionable error message in favour of a generic 'Setup failed with exit code 1'.

Also found at 1 additional location

• src/commands/cli/upgrade.ts:434-437

_{Identified by Warden find-bugs · HM4-JQ6}

[sentry-warden]

streamDecompressToFile still uses Bun.file().writer() after Node.js migration

streamDecompressToFile (line 557) calls Bun.file(destPath).writer(), which will throw ReferenceError: Bun is not defined at runtime under Node.js — replace with import { createWriteStream } from 'node:fs' and pipe chunks into a WriteStream.

Evidence

• streamDecompressToFile at line 557 calls Bun.file(destPath).writer(), a Bun-specific API.
• This function is called by both downloadNightlyToPath and downloadStableToPath, covering all binary download paths.
• The PR adds writeFile and setTimeout imports but leaves Bun.file().writer() untouched.
• Running under Node.js will produce ReferenceError: Bun is not defined on any upgrade attempt that decompresses a gzip download.
• The JSDoc comment at line 544 explicitly references Bun.file().writer() as the implementation strategy, confirming it was never converted.

_{Identified by Warden find-bugs · YQ3-LVT}

[sentry-warden]

Spawn errors silently absorbed by noop while function still returns true

When spawn emits an error event (e.g., ENOENT due to the TOCTOU window), noop silently absorbs it but the function still returns true, causing callers like openOrShowUrl to print "Opening in browser..." and skip the URL/QR-code fallback even though no browser was opened.

Evidence

• proc.on("error", noop) registers a no-op that discards any Error passed to it — the error is never surfaced to the surrounding scope.
• await setTimeout(500) does not await process exit or observe whether an error was emitted; it simply waits 500 ms unconditionally.
• return true on line 70 is always reached regardless of whether an error event fired during the 500 ms window.
• The caller openOrShowUrl branches on the return value: true → prints "Opening in browser..." and returns without showing the QR fallback; the fallback is only shown when openBrowser returns false.
• Node.js spawn always emits ENOENT/EACCES as an async error event — it never throws from the spawn() call itself — so the surrounding try/catch cannot catch these cases either.

_{Identified by Warden find-bugs · HK4-FVB}

[sentry-warden]

semver.compare throws on invalid version strings where Bun.semver.order returned null

Replace semverCompare(version, ...) calls with a null-safe wrapper (e.g. semver.valid(version) ? semverCompare(...) : null) or catch the TypeError, so malformed GHCR tag versions are silently skipped rather than crashing filterAndSortChainTags.

Evidence

• Bun.semver.order(v1, v2) returns null for invalid semver inputs; null === 1 is false, so invalid tags were silently skipped in the loop.
• The npm semver package's compare(v1, v2) (v7.x) constructs new SemVer(v) internally and throws TypeError: Invalid SemVer version for any non-conforming string.
• version at line 466 is derived from tag.slice(PATCH_TAG_PREFIX.length) with no prior semver validity guard — any unexpected GHCR tag (e.g. patch-latest, patch-) would produce a non-semver string.
• currentVersion and targetVersion are caller-supplied strings (from the running binary's version header) and are not validated before being passed in.
• The .sort() comparator at line 477 also calls semverCompare directly; a throw there would propagate uncaught from filterAndSortChainTags.

_{Identified by Warden find-bugs · ARU-GUD}

[sentry-warden]

TOCTOU: stat() called after readFile() may cache mismatched mtime and DSN content

Calling stat() after readFile() creates a race window: if the file is modified between the two calls, the cache stores the new file's mtime alongside the old file's DSN, causing future cache lookups to treat stale DSN data as fresh.

Evidence

• readFile(filepath) captures file content at time T1 (line 84).
• stat(filepath) is called separately at time T2 (line 88), after content is already processed.
• If the file is modified between T1 and T2, stats.mtimeMs reflects the new write, not the content that was read.
• sourceMtimes[filename] is then stored with this newer mtime (line 89), paired with the DSN extracted from the old content.
• On the next cache check, the stored mtime matches the actual file mtime, so the cache returns the stale DSN without re-scanning.

_{Identified by Warden find-bugs · L54-AGR}

[sentry-warden]

whichSync returns path with trailing \r on Windows when where.exe finds multiple matches

When where.exe outputs multiple results (CRLF line endings), stdout.trim().split("\n")[0] strips only the trailing CRLF of the last line — the first line retains its \r, so spawn receives e.g. C:\path\node.exe\r and fails with ENOENT. The ?? command.executable fallback in runSingleCommand never fires because whichSync returns a non-null (but corrupt) path. Fix: use (stdout.trim().split("\n")[0] ?? "").trimEnd() || null in src/lib/which.ts:61.

Evidence

• whichSync in src/lib/which.ts:40-61 calls execFileSync("where.exe", [command]) which outputs CRLF-separated lines on Windows.
• stdout.trim() only strips leading/trailing whitespace from the whole string; inner \r\n separators become \r\n with the final \n gone — leaving \r at the end of each non-last line.
• split("\n")[0] returns the first element, e.g. "C:\\Windows\\System32\\cmd.exe\r" with a trailing \r.
• runSingleCommand (outside hunk, line ~80) uses whichSync(command.executable) ?? command.executable; since the return value is non-null, the raw-name fallback never activates and the malformed path is forwarded to spawn.
• spawn with a path containing \r will throw ENOENT, caught by the outer try/catch returning { exitCode: 1 }.

Also found at 1 additional location

• src/lib/which.ts:63

_{Identified by Warden find-bugs · LXH-SZS}

[sentry-warden]

Timer not cleared when Promise.all rejects, child.kill() fires on dead process

If Promise.all rejects (e.g. readNodeStream rejects because child.stdout emits an error when the executable isn't found), execution jumps to the catch block and clearTimeout(timer) is never called. The timer fires later, sets timedOut = true, and calls child.kill() on an already-terminated process, which can throw an uncaught ESRCH exception and crash the process. Move clearTimeout(timer) into a finally block to fix this.

Evidence

• readNodeStream (command-utils.ts:311) attaches stream.on('error', reject), so any error event on child.stdout or child.stderr rejects the promise returned by readSpawnOutput.
• When the executable is not found (ENOENT), Node.js emits an error event on both the ChildProcess and on child.stdout/child.stderr, triggering this rejection path.
• clearTimeout(timer) appears only after the Promise.all await (line 104, context-after), not in a finally block, so it is skipped entirely when Promise.all rejects.
• The timer callback then fires after timeoutMs, calling child.kill() on a process that has already exited; process.kill(pid, ...) throws ESRCH if the PID no longer exists, producing an uncaught exception in the timer callback.

_{Identified by Warden find-bugs · J5Z-JEX}

[sentry-warden]

whichSync calls execFileSync with no timeout, blocking the event loop indefinitely

Both the Unix (/bin/sh -c 'command -v …') and Windows (where.exe) branches in the new whichSync helper omit a timeout option, so a hung shell (e.g. NFS stall, slow filesystem) blocks the entire Node.js process forever.

Evidence

• which.ts line 40: execFileSync("where.exe", [command], { encoding, stdio, env }) — no timeout.
• which.ts line 50: execFileSync("/bin/sh", ["-c", …], { encoding, stdio, env }) — no timeout.
• execFileSync is synchronous and blocks the Node.js event loop for its entire duration; without a timeout the process can hang indefinitely.
• isBashAvailable in shell.ts (line ~295) calls whichSync("bash") inline, making any caller (e.g. completions setup) susceptible to the same hang.

_{Identified by Warden find-bugs · 96U-DKF}

[sentry-warden]

Inner catch silently discards all readFile errors, risking GITHUB_PATH content loss

The catch swallows every readFile error, not just ENOENT. If the file exists but is temporarily unreadable (e.g., a transient permission issue), content stays "" and the subsequent writeFile overwrites the file with only the new directory — silently losing all previously-appended PATH entries.

Evidence

• The replaced Bun.file(path).exists() guard returned false only when the file did not exist; any other I/O error would propagate.
• The new inner catch {} (lines 302-305) has no condition — it catches all errors, including EACCES, EIO, etc.
• When content is "" and the outer writeFile succeeds, every previous entry in $GITHUB_PATH is permanently discarded.
• The outer catch only fires if writeFile also fails, so data loss is possible without any returned error signal.

_{Identified by Warden find-bugs · R6N-BLP}