[Bug] app-boot resolver requires node-addon-require-builtin unconditionally — fatal on Android, while hmr already has the --expose-internals fallback

[zexadev]

What happens

On Android (dsh running inside an app sandbox, Node 24.18.0, arm64), dsh web dies at startup:

dsh: fatal uncaught exception: Error: dsh: host preparation failed:
     No usable native binding found for node-addon-require-builtin-android-arm64 (auto)
    at boot (.../@deepseek-ai/dsh-app-boot/lib/index.js)

node-addon-require-builtin publishes prebuilds for linux/darwin/win only, so on Android requiring it always throws. Related: #6982 (same addon, 0.1.6-alpha.2) and #9093 (building the addon for Android by hand).

The repo already solves this, just not here

packages/boot/hmr/src/package-manifest.ts:

/** Same lookup as the vendored Loader's `requireInternal`: `--expose-internals` first, then the builtin addon. */
function requireInternal(id: string): unknown {
  const require = createRequire(import.meta.url)
  if (process.execArgv.includes('--expose-internals')) {
    try { return require(id) } catch (_error) { /* ... */ }
  }
  try {
    return (require('node-addon-require-builtin') as { requireBuiltin(id: string): unknown }).requireBuiltin(id)
  } catch (_error) { /* ... */ }
}

packages/boot/app-boot/src/profile-resolution/resolver.ts:614 goes straight to the addon instead:

function internalModules(): InternalModules {
  const require = createRequire(import.meta.url)
  const addon = require('node-addon-require-builtin') as { requireBuiltin(moduleId: string): unknown }
  const esmModule = addon.requireBuiltin('internal/modules/esm/loader') as { ... }
  // four more requireBuiltin calls

So a process started with --expose-internals — which can reach every internal module this function needs without any native code — still dies here.

This is what regressed Android between 0.1.5 and 0.2. In 0.1.5 the only consumer on the startup path was the vendored cordis loader, which has the fallback, so --expose-internals was enough to boot. 0.2 added this resolver, and it is still written this way on master at dsh-v0.2.1-alpha.1.

Measured

Redmi 23113RKC6C, Android 16, arm64, Node 24.18.0 started with --expose-internals. All five internal modules resolve through a plain require, and every shape check internalModules() performs afterwards passes:

{"node":"24.18.0","modern":true,"resolveSync":"function","moduleJob":"function",
 "resolveFilename":"function","getCjsConditions":"function",
 "getDefaultConditions":"function","defaultResolve":"function"}

Worker threads inherit execArgv, and the internal require works there too — which matters because the bundled output ships a second copy of this function in lib/worker/profile-resolution-bootstrap.js.

With internalModules() changed to try --expose-internals first, dsh 0.2.0-rc.2 starts normally on the device and prints its dsh web: http://127.0.0.1:<port> line. Nothing else was changed.

Suggested fix

Have internalModules() use the same lookup hmr already uses — --expose-internals first, the addon second. That costs nothing on platforms where the addon exists, and removes the hard dependency on a prebuild for this code path.

It does not make Android a supported target by itself, but it does mean one less platform-specific binary standing between dsh and any environment the addon was never built for.

[hZsFN]

Measured on Windows x64 — and the cost is not Android-only. It is paid on every startup on every platform where the addon does load successfully.

Same code path (internalModules() in dsh-app-boot/lib/index.js), Electron 44.7.0 / Node 24.21.0, DSH Desktop 0.2.1-rc.2, app started with --expose-internals:

path	run 1	run 2	run 3
node-addon-require-builtin (current)	1147.3 ms	1125.4 ms	1169.5 ms
createRequire(import.meta.url)(id)	0.056 ms	0.057 ms	0.059 ms

Three interleaved runs, a fresh process each, same Electron/Node instance used for both arms.

Correctness: all five modules return values strictly === between the two paths, and every shape check internalModules() performs afterwards passes. A second harness imported the real, unmodified app-boot module out of the shipped app.asar and ran it in Electron-as-node with the flag on and off: with the flag the install hook succeeded and dispose restored state; without the flag the original cost came back unchanged. The cases and mutations probes were byte-identical between arms across 12 interleaved runs, plus 4 no-flag runs.

So where the addon works, this one call spends ~1.1 s inside the install phase doing what a direct require does in ~60 µs. I did not establish a full cold-start timing baseline, so I am not claiming a measured end-to-end speedup — but the per-call cost is reproducible in isolation, and it sits on the startup path for every platform, not just the Android case above.

The fix described in the original post (--expose-internals first, addon second — same lookup hmr's requireInternal already uses) removes both the Android crash and this cost.

[hZsFN]

Follow-up: what entry resolution actually costs inside a full cold startup

Same machine as my comment above (Desktop 0.2.1-rc.2, Electron 44.7.0 / Node 24.21.0, win32-x64, ~225 plugins, launched with --expose-internals). Main-thread sampling across one boot: 164 apply calls, ~40 s window.

The 5.39 s before fibers first reach all-active, broken down by syscall (package-entry resolution only, ~660 packages):

kind	time	share
internalModuleStat	2156 ms	40.0%
realpathSync	1493 ms	27.7%
lstat / statSync	1337 ms	24.8%
readFileUtf8	191 ms	3.5%
structuredClone and misc	217 ms	4.0%

So ~92% of that phase is stat/realpath on package entries — the same work the resolver does per candidate prefix. Two observations that may save someone a day:

• Pausing the AV product made the phase only ~40% faster. It is not fs filtering; it is the number of resolution attempts.
• I tried shortening the resolver prefix list (saved ~10 realpathSync calls per resolution round), but different rounds disagreed on which prefix wins, so I did not ship it. A cache keyed by (parent dir, specifier) is probably the higher-leverage shape, but I have no end-to-end number for it.

One item on the same startup path that is not resolver-related, for completeness: the usage poller calls configuration() synchronously on every refresh, and that function re-reads the entire config file, structuredClones it, then runs existsSync per namespace — 3.1 s per call (readFileUtf8 858 / structuredClone 848 / existsSync 733). A 3 s-TTL namespace cache dropped the endpoint p50 from 1.15–1.82 s to 115 ms and removed the matching stall.

Caveats, because they matter here: the cache win has one warm sample behind it (the pre-active speedup is probably warm-start, not the patch), there is no click-to-interactive A/B yet, and the 4–11 s stalls that remain after everything is active are still unattributed (loading=[none]).

I posted the same data as an update under #10081; happy to fold it into one thread if you prefer.