Skip to content

feat: enabled cross-origin storage emscripten build for bundler-friendly build - #179

Open
jurerotar wants to merge 1 commit into
sqlite:mainfrom
jurerotar:feat/cos
Open

jurerotar wants to merge 1 commit into
sqlite:mainfrom
jurerotar:feat/cos

Conversation

@jurerotar

Copy link
Copy Markdown
Contributor

We enable COS only for bundler-friendly build, since sqlite3.mjs is used only in deprecated promiser and worker builds and node.js build has no use for this.

Addresses #178.

@tomayac tomayac left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot for this, @jurerotar! This looks great! Two quick remarks:

The shipped sqlite3-worker1.mjs imports ./sqlite3.mjs, which is built without the COS flag, so Workers don't get the COS benefits. Since many apps run SQLite in a worker for OPFS, could we also pass emcc.flags.esm=-sCROSS_ORIGIN_STORAGE and have the hash step patch both loaders? The Wasm file is the same for both main thread and Worker, so the hash is likewise the same.

This is something Claude noted, so passing it on:

emcc.flags.bundler=… on the command line replaces the value upstream's mkwasmbuilds.c generates. That's empty today (zEmccExtra = 0 for .bundler), but a quick check in the script that upstream's value is still empty would stop us from silently dropping flags SQLite adds later.

@jurerotar

jurerotar commented Oct 25, 2026 •

Copy link
Copy Markdown
Contributor Author

The shipped sqlite3-worker1.mjs imports ./sqlite3.mjs, which is built without the COS flag, so Workers don't get the COS benefits. Since many apps run SQLite in a worker for OPFS, could we also pass emcc.flags.esm=-sCROSS_ORIGIN_STORAGE and have the hash step patch both loaders? The Wasm file is the same for both main thread and Worker, so the hash is likewise the same.

Sure! I was purposely excluding sqlite3.mjs, because worker1 and promiser apis are deprecated, but honestly, no reason why improvements can't be applied to them anyway. I'll fix this right up!

Edit: Alrighty, tiny problem. sqlite3.mjs uses a custom instantiateWasm. Stephan explained in a previous discussion this is done so SQLite has ability to control the loading. If we want COS enabled, we have to override this with Emscripten's loading mechanism that supports COS. This should be fine, but in case upstream changes their module loading for any reason, we won't receive that. I'm not sure what the best solution here is, I'm inclined to leave worker1 and promiser APIs as they are, since we mention they won't receive updates, but we can also overwrite it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants