better-sqlite3 ABI mismatch crashes extension on WSL 2 — NODE_MODULE_VERSION 137 vs 127

[mohamedEmad23]

better-sqlite3 ABI mismatch crashes extension on WSL 2 — NODE_MODULE_VERSION 137 vs 127

Summary

The extension fails to activate on WSL 2 (Ubuntu 24 LTS) due to a native module ABI mismatch. The bundled better-sqlite3 binary was compiled against NODE_MODULE_VERSION 137 (Node.js 24.x), but VSCode Server's internal Node.js runtime requires NODE_MODULE_VERSION 127 (Node.js 22.x).

This results in a complete activation failure — all extension commands (Code Graph: Build Graph, etc.) are silently unregistered and show "command not found" when invoked.

---

Environment

Field	Value
OS	Windows 11 (x64 10.0.26200) + WSL 2 Ubuntu 24.04 LTS
VSCode Version	1.112.0
VSCode Commit	07ff9d6178ede9a1bd12ad3399074d726ebe6e43
VSCode Internal Node.js	22.22.0 (NODE_MODULE_VERSION 127)
Electron	39.8.0
Extension Version	0.1.1
Extension install location	~/.vscode-server/extensions/tirth8205.code-review-graph-0.1.1

---

Error

From Output → Extension Host:

2026-03-25 18:33:15.195 [info] ExtensionService#_doActivateExtension tirth8205.code-review-graph,
  startup: false, activationEvent: 'onView:codeReviewGraph.codeGraph'
2026-03-25 18:33:15.201 [error] Activating extension tirth8205.code-review-graph failed due to an error:
2026-03-25 18:33:15.201 [error] Error: Cannot find module 'better-sqlite3'

Require stack:

/home/main-emad/.vscode-server/extensions/tirth8205.code-review-graph-0.1.1/dist/extension.js
/home/main-emad/.vscode-server/bin/07ff9d6178ede9a1bd12ad3399074d726ebe6e43/out/vs/workbench/api/node/extensionHostProcess.js

After manually running npm install in the extension directory, the error changes to:

The module '.../tirth8205.code-review-graph-0.1.1/node_modules/...' was compiled against
a different Node.js version using NODE_MODULE_VERSION 137.
This version of Node.js requires NODE_MODULE_VERSION 127.
Please try re-compiling or re-installing the module.

---

Additional Context

• The issue is specific to WSL 2 / Linux remote environments where VSCode Server runs its own Node.js binary separate from the system Node.
• On Windows-native VSCode installs this may not manifest, which could explain why it wasn't caught before publishing.
• prebuild-install (used during npm install) is also deprecated and should be replaced with node-gyp or a WASM-based approach.

[tirth8205]

This is a VS Code extension issue with better-sqlite3 native bindings on WSL2. The fix requires building against the correct Node.js ABI. We'll investigate shipping prebuilt binaries for multiple Node.js versions or switching to a WASM-based SQLite binding.

[tirth8205]

Improvement pushed: the extension now has graceful error handling for ABI mismatches with actionable instructions (npm rebuild better-sqlite3). A full fix would require switching to a WASM-based SQLite binding or shipping prebuilt binaries for multiple Node.js versions — that's tracked for a future release.

[tirth8205]

This is a known limitation with the VS Code extension on WSL 2 — the pre-built better-sqlite3 binary is compiled for a different Node.js ABI version. We've added graceful error handling for this case. A full fix would require WASM-based SQLite or multi-ABI prebuilds, which is on the roadmap for a future extension release.

[tirth8205]

Valid VS Code extension bug. The extension bundles better-sqlite3 prebuilt for a specific Node.js version (NODE_MODULE_VERSION 137 = Node 24.x), but VS Code Server on WSL2 uses Node 22.x (NODE_MODULE_VERSION 127), causing an ABI mismatch.

The fix requires either:

1. Shipping prebuilds for both Node 22.x and 24.x NODE_MODULE_VERSIONs in the extension
2. Using a WASM-based SQLite alternative (e.g. sql.js or wa-sqlite) that avoids native ABI issues entirely
3. Using node-gyp to rebuild better-sqlite3 at install time for the target environment

Option 2 is the most robust for cross-environment support. This is a valid open bug for the VS Code extension.

[Bakul2006]

Hey, @tirth8205 I looked up your conversation on this issue And found that using WASM is a great approach but what I found Is Instead of binaries due to the mismatch which we are facing for now we are preffering the web assembly WASM approach but it has a significant concern it can just slow down the speed and which would cause the Performance adversley So How I approached this is Can we do a Hybrid of both -:

1. If the ABI matches up with the node version we will use the Binary
2. If it goes to fallback then We will approach the WASM path.
   Please correct me If I am thinking in a wrong direction