Fix: Ensure compatibility with Node.js >= 25 and Bun

[Cleboost]

Context & Problem

Node.js 25.x (and newer versions relying on recent V8 releases) introduced a regression in the new V8 Turboshaft WebAssembly compiler pipeline. During heavy WASM compilation workloads—such as
compiling tree-sitter grammars—the engine hits a native allocator limit and crashes with a fatal process out-of-memory error: Fatal process out of memory: Zone .

Previously, CodeGraph had a hard blocking check on Node.js versions >= 25 to prevent these unexpected mid-indexing crashes. However, this caused two issues:

1. It blocked users running recent Node.js releases even if they wanted to bypass or run safely.
2. It incorrectly blocked users running Bun (since Bun's Node compatibility layer advertises a Node version higher than 25 in process.versions.node ), even though Bun uses WebKit's JavaScriptCore
   (JSC) and is entirely unaffected by V8-specific bugs.

Proposed Changes

This PR introduces a robust, transparent compatibility layer for Node.js >= 25 and Bun without breaking backward compatibility:

1. Bun Auto-Detection:
   • Skips the version compatibility block entirely if 'bun' in process.versions is detected. This allows commands like bun cli to run natively and safely.
2. Transparent Node.js Respawning:
   • For Node.js >= 25 runtimes, the script now dynamically checks if the --no-turboshaft V8 flag is active in process.execArgv .
   • If missing (and the unsafe override env variable is not set), the CLI transparently spawns a child process of itself prepended with --no-turboshaft . This disables V8's problematic Turboshaft
   pipeline and falls back to the highly stable TurboFan compiler tier for WebAssembly, preventing the Zone allocator crash entirely.
   • The parent process waits for the child and inherits its exit status code.

fix #183

[PylotLight]

Also hoping to get this one in as I primarily only use bun making this incompatible, and the latest change didn't fix it.

[colbymchenry]

Thanks for digging into this, @Cleboost — the Bun-vs-V8 distinction and the respawn idea were good instincts. It's been overtaken by changes to how CodeGraph is packaged and how the crash is handled, so the specific approach here is no longer the right fit.

1. The respawn mechanism already exists on main — relaunchWithWasmRuntimeFlagsIfNeeded re-execs with --liftoff-only. That matters because --liftoff-only is the only flag that actually prevents the turboshaft Zone OOM; --no-turboshaft / --no-wasm-tier-up were tested and do not stop it. So switching to --no-turboshaft would regress the fix.

2. The version block barely fires for real users anymore. The published package is a thin installer (bin → npm-shim.js). A user's runtime — Node 25, Bun, anything — only runs the shim, which execs the bundled Node 24 + node:sqlite. So bunx @colbymchenry/codegraph now hops to bundled Node 24 and never hits the block. That's why #183 (the bunx report this PR cites) is already closed.

3. The Bun-skip would make things worse, not better. node:sqlite is now CodeGraph's only SQLite backend, and no Bun version implements node:sqlite — Bun's compat matrix lists it 🔴 Not implemented, and the tracking issue (oven-sh/bun#20412) is still open. I verified locally: Bun dies at init before any DB work. So on the one path where Bun would run CodeGraph directly (dev-from-source), skipping the block trades a clean "unsupported runtime" message for a cryptic mid-init crash. The hard block is the safer behavior.

Closing as superseded — appreciate the effort and the clear writeup. 🙏