Web target crashes on boot: openDatabaseSync is not a function

[kmch4n]

Summary

The Web target does not start. npm run web serves a blank page and throws before the first screen renders:

TypeError: (0 , _expoSqlite.openDatabaseSync) is not a function
    at Object.get [as ./_layout.tsx]
    at metroContext
    at loadRoute
    at getDirectoryTree
    at getRoutes
    at ContextNavigator

React then reports An error occurred in the <ContextNavigator> component, and nothing mounts.

Observed on e2d5e05 in Chrome against npx expo start --web (port 8081, bundle built successfully — this is a runtime failure, not a bundling one).

The chain

Three facts, each verified:

1. src/database/index.ts:6 calls openDatabaseSync("snowlog.db", …) at module scope, so merely importing the module opens the database.
2. src/database/index.ts has no .web.ts companion. Every repository under src/database/repositories/ has one; the module that creates the Drizzle singleton does not.
3. expo-sqlite's web build does not provide that export. node_modules/expo-sqlite/build/ExpoSQLite.web.js contains no openDatabaseSync — grep returns nothing, while the native build has it.

The import that pulls it in is src/app/_layout.tsx:20 — import { db } from "@/database", needed for useMigrations.

Why _layout.web.tsx does not save us

src/app/_layout.web.tsx exists specifically to avoid this. Its header comment says so:

Web用ルートレイアウト
expo-sqlite / Drizzle はブラウザ非対応のため、DBマイグレーションをスキップする

It skips migrations and never imports @/database. But the stack frame reads Object.get [as ./_layout.tsx] — Expo Router's require.context route tree loaded the native _layout.tsx, so the web variant never ran.

This is the part worth confirming before choosing a fix: Metro's platform resolution applies to import specifiers, so @/database/repositories/videoRepository does correctly become videoRepository.web.ts inside whichever layout loads. It is the route-file lookup itself that appears not to prefer the .web.tsx variant. Whether that is an Expo Router v4 behaviour, a config gap, or something about _layout specifically, I did not determine.

Why this matters more than it looks

.memory/wiring.md and SnowLog.md §12.3 both describe Web as a working preview surface for layout checks, and the repository maintains 15 native/.web module pairs to support it. #71 and #74 were both filed and fixed to keep those shims honest.

If the app cannot boot on Web, none of that is reachable, and the acceptance criterion in #74 — "bulk delete, bulk favourite, custom-tag delete and technique reorder all work on Web without a TypeError" — cannot be exercised at all. The parity work still stands on its own (the exports exist and a test now enforces them), but it has not been, and currently cannot be, confirmed by clicking.

Why this needs a decision rather than a patch

There are three defensible responses and they differ in scope:

1. Add src/database/index.web.ts — a stub exporting a db that throws or no-ops. Smallest change; makes the native _layout.tsx survive on Web. But it papers over the fact that the wrong layout is loading, and the native layout would then run its whole startup sequence (migrations, seeding, thumbnail migration, orphan cleanup) against a fake database.
2. Make Expo Router pick up _layout.web.tsx — the intended design. Needs a diagnosis I did not finish, and may not be supported for _layout files in Expo Router v4.
3. Drop the Web target — delete the 15 shims, the four .web.tsx screens, and the parity test, and say plainly in SnowLog.md that Web is unsupported. That removes a standing maintenance cost for a surface that is currently broken and, by the repo's own description, only ever served layout previews.

Option 3 is a product call. Options 1 and 2 differ in how much they actually fix. Not choosing on the maintainer's behalf.

How to reproduce

npx expo start --web

Open http://localhost:8081, then read the browser console. The page is blank; the exception above is the first entry after the bundle loads.

Acceptance criteria

• npm run web renders the app, or SnowLog.md and .memory/wiring.md state that Web is unsupported and the shim infrastructure is removed.
• If Web stays supported: the four actions listed in Web shims are missing 10 exports; four break user actions on Web #74 are clicked through without a TypeError.

Related

• Web shims are missing 10 exports; four break user actions on Web #74 — Web shim export parity. Its shim fixes are committed and enforced by a test, but its Web click-through could not be performed because of this.
• Web shim for mediaService omits isSyntheticAssetId, breaking delete paths #71 — the earlier single instance of shim drift.

[kmch4n]

Maintainer position: deprioritised

Recorded so this issue is not read as awaiting a decision. Asked which of the three options to take, the maintainer's answer was that the Web application is broken and is not a concern right now.

That settles the choice between the three responses listed above only in the sense that none of them is being taken yet. Option 3 — dropping the Web target and its 15 shims outright — remains available and is the one that would actually remove maintenance cost; it is not being taken unilaterally because deleting a documented platform is a product decision.

Two consequences worth writing down:

• Web shims are missing 10 exports; four break user actions on Web #74's remaining acceptance criterion stays unmet indefinitely. Its shim parity is fixed and enforced by scripts/tests/webShimParity.test.cjs, but the click-through it asks for cannot happen while the app does not boot on Web.
• The .web shim infrastructure is still being maintained. The parity test will keep failing the suite whenever a shim drops an export, and that cost continues to be paid for a surface that currently does not run. If Web is not coming back, deleting the shims and the parity test together is the coherent end state.

Relabelled priority:low.