src/storage/db.ts imports bun:sqlite statically:
import { Database } from "bun:sqlite";
bun:sqlite is a Bun-only built-in module. When the storage layer (and anything that transitively imports it — sessions.ts, migrations.ts, etc.) is loaded under plain Node — e.g. via node node_modules/.bin/vitest run — the import fails to resolve, so storage-related tests cannot run under Node/Vitest at all, only when Vitest itself happens to execute under the Bun runtime (bunx vitest run).
This makes it impossible to verify storage-layer correctness in a Node-only environment (CI runners without Bun, contributors without Bun installed, tooling that assumes plain Node).
Proposed fix: load bun:sqlite lazily at runtime (via createRequire) instead of statically, and fall back to Node's built-in node:sqlite (DatabaseSync, stable enough as of Node 22.5+) when bun:sqlite isn't resolvable. Both backends implement the same internal Database interface, so SQLiteDatabase consumers are unaffected.
src/storage/db.tsimportsbun:sqlitestatically:bun:sqliteis a Bun-only built-in module. When the storage layer (and anything that transitively imports it —sessions.ts,migrations.ts, etc.) is loaded under plain Node — e.g. vianode node_modules/.bin/vitest run— the import fails to resolve, so storage-related tests cannot run under Node/Vitest at all, only when Vitest itself happens to execute under the Bun runtime (bunx vitest run).This makes it impossible to verify storage-layer correctness in a Node-only environment (CI runners without Bun, contributors without Bun installed, tooling that assumes plain Node).
Proposed fix: load
bun:sqlitelazily at runtime (viacreateRequire) instead of statically, and fall back to Node's built-innode:sqlite(DatabaseSync, stable enough as of Node 22.5+) whenbun:sqliteisn't resolvable. Both backends implement the same internalDatabaseinterface, soSQLiteDatabaseconsumers are unaffected.