Summary
The sqlite3 shell feature group can be imported and wired up per the README, but every invocation fails at runtime:
sqlite3: worker error: sqlite3 worker failed to load: sqlite3 worker not found. Run 'pnpm build' to compile the worker.
The error tells the user to run pnpm build, which isn't actionable from an installed npm package — it reads like a build step that didn't run before publish.
Reproduce
Clean install, nothing else in the picture:
npm init -y
npm install @cloudflare/computer@0.2.0
Wire the group into WorkerShellBackend as documented:
import sqliteModules from "@cloudflare/computer/shell/sqlite";
new WorkerShellBackend({ /* … */ commands: [sqliteModules] })
Then:
sqlite3 /demo/app.db "CREATE TABLE t(k TEXT); SELECT 1;"
# exitCode 1
# stderr: sqlite3 worker failed to load: sqlite3 worker not found. Run 'pnpm build' to compile the worker.
Other feature groups from the same mechanism work fine — curl and jq both behave as documented (verified against a live API), so this looks specific to the sqlite group rather than to how the groups are wired.
Diagnosis
In the published tarball, dist/backends/worker-shell/shell/sqlite.js references sqlite3-worker.js but never defines it. Against a clean npm install of 0.2.0:
references to sqlite3-worker.js: 1
has module content key ("sqlite3-worker.js": { "js": …): false
error string present: true
Every other module in that file ships as a "<name>.js": { "js": "…" } entry in the inlined module map — including the sql.js WASM payload, which is present. The sqlite3-worker.js entry point is the one piece missing, so the loader looks it up, misses, and hits the pnpm build branch.
So the WASM made it into the tarball but its worker entry point didn't — consistent with a build/publish step that doesn't emit (or doesn't include) that artifact.
Environment
@cloudflare/computer@0.2.0
wrangler@4.123.0, workerd@1.20260811.1
- macOS 25.2.0, local
wrangler dev
- Backend: worker-shell (isolate),
nodejs_compat + experimental + enable_ctx_exports
Note
If sqlite3 is known-incomplete in this preview, dropping a line in the README's feature-group list would be enough — the current failure mode points at a pnpm build that an npm consumer can't run.
Summary
The
sqlite3shell feature group can be imported and wired up per the README, but every invocation fails at runtime:The error tells the user to run
pnpm build, which isn't actionable from an installed npm package — it reads like a build step that didn't run before publish.Reproduce
Clean install, nothing else in the picture:
Wire the group into
WorkerShellBackendas documented:Then:
Other feature groups from the same mechanism work fine —
curlandjqboth behave as documented (verified against a live API), so this looks specific to the sqlite group rather than to how the groups are wired.Diagnosis
In the published tarball,
dist/backends/worker-shell/shell/sqlite.jsreferencessqlite3-worker.jsbut never defines it. Against a cleannpm installof0.2.0:Every other module in that file ships as a
"<name>.js": { "js": "…" }entry in the inlined module map — including the sql.js WASM payload, which is present. Thesqlite3-worker.jsentry point is the one piece missing, so the loader looks it up, misses, and hits thepnpm buildbranch.So the WASM made it into the tarball but its worker entry point didn't — consistent with a build/publish step that doesn't emit (or doesn't include) that artifact.
Environment
@cloudflare/computer@0.2.0wrangler@4.123.0,workerd@1.20260811.1wrangler devnodejs_compat+experimental+enable_ctx_exportsNote
If
sqlite3is known-incomplete in this preview, dropping a line in the README's feature-group list would be enough — the current failure mode points at apnpm buildthat an npm consumer can't run.