chore: 3.53.0 release

[jurerotar]

No description provided.

[tomayac]

All tests still fail. Is this ready to merge despite?

[jurerotar]

Seems like @vapier's http-server was deleted, thus the pipeline fails.

[jurerotar]

@sgbeal, sorry to bother you! Any ideas on this pipeline failing? Has SAHPool's init changed?

[vapier]

haha crazy that someone used my vapier/http-server fork. I deleted it once my PRs were (finally) merged back into the canonical http-party/http-server. they sadly haven't made a new release, but if you're simply looking for cors support, you should be able to pin to that project now to get the functionality you need.

[sgbeal]

This part is curious:

in Worker (browser)
Error: Worker error: Uncaught Error: Expecting vfs=opfs|opfs-wl URL argument for this worker
 ❯ worker.onerror src/__tests__/sqlite3-sahpool-vfs.browser.test.js:20:14

SAHPool does not load sqlite3-opfs-async-proxy.js, and that's where that error comes from. If any test is trying to explicitly load that file then it will definitely fail as of 3.53. That file must now distinguish between the "opfs" and "opfs-wl" VFSes so now requires a URI flag. That file is only intended to be loaded from the code which inits the VFSes.

[sgbeal]

BTW: there's a new mechanism which can be used to force the library to not load "opfs" or "opfs-wl":

https://sqlite.org/wasm/doc/trunk/cookbook.md#disable-vfs

That will keep it from loading sqlite3-opfs-async-proxy.js.

[jurerotar]

Here's the relevant test code:

sqlite-wasm/src/__tests__/workers/sqlite3-sahpool.worker.js

Lines 5 to 7 in 29a59fe

	const sqlite3 = await sqlite3InitModule();
	const opfsSahPool = await sqlite3.installOpfsSAHPoolVfs();
	let db = new opfsSahPool.OpfsSAHPoolDb('/test-sahpool-worker.sqlite3');

This worker is invoked here:

sqlite-wasm/src/__tests__/sqlite3-sahpool-vfs.browser.test.js

Lines 3 to 9 in 29a59fe

	test('OpfsSAHPoolVfs sanity check in Worker (browser)', async () => {
	const worker = new Worker(
	new URL('./workers/sqlite3-sahpool.worker.js', import.meta.url),
	{
	type: 'module',
	},
	);

I haven't changed the tests at all in this PR, so it appears that the way to use SAHPool has changed now. This test is also based on real-life usage. If you inspect the test, you'll see that we don't try to manually load sqlite3-opfs-async-proxy.js.

This appears to be a breaking change from the last version we published, so we'll either need to add a migration guide, or add a patch upstream so that existing way still works.

@sgbeal, please advise on how to approach this one.

[sgbeal]

@sgbeal, please advise on how to approach this one.

The error is being triggered not from SAHPool, but from the external file sqlite3-opfs-async-proxy.js, which itself is being loaded by the part which attempts to initialize the "opfs" and "opfs-wl" VFSes. It is normal and expected for an async error message to be triggered for the case it's complaining about, but it won't (or should not) affect the library except to disable those two specific VFSes.

i'm unable to reproduce this with the upstream code so am at a loss as to what is trying to load the async proxy without the proper URI parameters. That worker is loaded from precisely one place upstream and always includes the required arguments (which are new in 3.53 but this file has always been an internal detail, not part of the public API, so clients aren't loading it manually). The relevant part is:

        const options = opfsUtil.options;
        let proxyUri = options.proxyUri +(
          (options.proxyUri.indexOf('?')<0) ? '?' : '&'
        )+'vfs='+vfsName;
        //sqlite3.config.error("proxyUri",options.proxyUri, (new Error()));
        const W = opfsVfs.worker =
//#if target:es6-bundler-friendly
              (()=>{
                /* _Sigh_... */
                switch(vfsName){
                  case 'opfs':
                    return new Worker(new URL("sqlite3-opfs-async-proxy.js?vfs=opfs", import.meta.url));
                  case 'opfs-wl':
                    return new Worker(new URL("sqlite3-opfs-async-proxy.js?vfs=opfs-wl", import.meta.url));
                }
              })();
//#elif target:es6-module
        new Worker(new URL(proxyUri, import.meta.url));
//#else
        new Worker(proxyUri);
//#/if

My assumption is that the bundler-friendly mechanism is to blame, but i've no way to confirm that in the upstream tree. Both the vanilla and non-bundler ESM modes are tested in several apps upstream and do not reproduce this.

i unfortunately don't currently have any ideas about how to resolve this.