You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
package.json declares "engines": { "node": ">=22" } and pins "packageManager": "pnpm@11.20.0" — but pnpm 11 hard-requires the node:sqlite builtin, which is flag-gated until late in the Node 22/23 lines. The engines range therefore admits a band of Node versions on which the pinned package manager cannot start at all, and the contributor sees a pnpm stack trace rather than anything naming the real constraint. Windows contributors, who tend to sit on nvm-windows-installed even-numbered releases, walk straight into it.
Adjacent to #167 (corepack missing on Node 25+ breaks the documented quickstart) but a different clause: #167 is about how pnpm gets installed; this is about engines promising Node versions the pinned pnpm cannot run on.
Observed ladder (Windows 11, nvm-windows, clean checkout of main)
Node 20.18.0 — npm i -g pnpm@11 && pnpm install: ERR_UNKNOWN_BUILTIN_MODULE from pnpm's own bundle (no node:sqlite in 20.x). Engines says >=22, fair — but the error names nothing actionable.
Node 23.3.0 (satisfies >=22) — npx pnpm@11 install: ERR_UNKNOWN_BUILTIN_MODULE: No such built-in module: node:sqlite at ../store/index/lib/index.js. Engines-compliant Node, pinned pnpm, cold stop.
Node 22.23.2 (WSL, same machine): everything works — which is the point: the working floor is a late 22.x, not ">=22".
Why it matters
The method doc's own thesis is that agents (and people) hedge when "the environment can't run anything." A first-touch contributor on an engines-compliant Node gets a pnpm internals stack trace before reaching pnpm install's first byte of output. Nothing in README, CONTRIBUTING, or the error path names node:sqlite or the real minimum.
Summary
package.jsondeclares"engines": { "node": ">=22" }and pins"packageManager": "pnpm@11.20.0"— but pnpm 11 hard-requires thenode:sqlitebuiltin, which is flag-gated until late in the Node 22/23 lines. The engines range therefore admits a band of Node versions on which the pinned package manager cannot start at all, and the contributor sees a pnpm stack trace rather than anything naming the real constraint. Windows contributors, who tend to sit on nvm-windows-installed even-numbered releases, walk straight into it.Adjacent to #167 (corepack missing on Node 25+ breaks the documented quickstart) but a different clause: #167 is about how pnpm gets installed; this is about
enginespromising Node versions the pinned pnpm cannot run on.Observed ladder (Windows 11, nvm-windows, clean checkout of
main)Every rung verbatim, same repo, same day:
corepack pnpmvia a stale shim:ERR_VM_DYNAMIC_IMPORT_CALLBACK_MISSING(corepack relic; Quickstart fails on Node 25+: corepack is no longer bundled, so corepack enable and pnpm dev cannot run #167 territory).npm i -g pnpm@11 && pnpm install:ERR_UNKNOWN_BUILTIN_MODULEfrom pnpm's own bundle (nonode:sqlitein 20.x). Engines says >=22, fair — but the error names nothing actionable.>=22) —npx pnpm@11 install:ERR_UNKNOWN_BUILTIN_MODULE: No such built-in module: node:sqliteat../store/index/lib/index.js. Engines-compliant Node, pinned pnpm, cold stop.Why it matters
The method doc's own thesis is that agents (and people) hedge when "the environment can't run anything." A first-touch contributor on an engines-compliant Node gets a pnpm internals stack trace before reaching
pnpm install's first byte of output. Nothing in README, CONTRIBUTING, or the error path namesnode:sqliteor the real minimum.Suggested fix (small)
engines.nodeto the actual floor pnpm 11 needs (the first release line with unflaggednode:sqlite— e.g.>=22.13), or document the floor in CONTRIBUTING next to the corepack note from Quickstart fails on Node 25+: corepack is no longer bundled, so corepack enable and pnpm dev cannot run #167.package.jsonpreinstallor the quickstart:node -e "require('node:sqlite')"with a one-line human message when it throws.Happy to send the PR for whichever shape you prefer — it pairs naturally with the #167 quickstart correction.