Repository navigation
Missing typing for sqlite3Worker1Promiser #155
Description
Activity
Hey, thank you for raising this! 😄
I'll take a look and keep you updated!
Reacted by Thomas Steiner and realGrissSorry about this! I've prepared a PR (#156) that should resolve this issue. I've also touched a bit on the types, specifically
Worker1Promisertype is now exported, so you'll be able to use it for explicitly typing your variable, should you need to, and specific calls likeconfig-getshould now no longer require redundant second arguments 😄Reacted by realGrissThe Node.js version (
dist/node.mjs) does not export it. I think this is the problem.@realGriss, new release was just published, please let me know if the issue is solved! 😄
Types seems to work fine now. Thanks for the quick update.
The only problem I'm running into is that I get a error with the current example:
import { sqlite3Worker1Promiser, type Worker1Promiser, } from '@sqlite.org/sqlite-wasm'; const log = console.log; const error = console.error; const initializeSQLite = async () => { try { log('Loading and initializing SQLite3 module...'); const promiser = await new Promise<Worker1Promiser>((resolve) => { sqlite3Worker1Promiser({ onready: resolve, }); }); log('Done initializing. Running demo...'); const configResponse = await promiser('config-get'); log('Running SQLite3 version', configResponse.result.version.libVersion); const openResponse = await promiser('open', { filename: 'file:mydb.sqlite3?vfs=opfs', }); const { dbId } = openResponse; log( 'OPFS is available, created persisted database at', openResponse.result.filename.replace(/^file:(.*?)\?vfs=opfs$/, '$1'), ); // Your SQLite code here. } catch (err) { if (!(err instanceof Error)) { err = new Error(err.result.message); } error(err.name, err.message); } }; await initializeSQLite();TypeError: Cannot create property 'dbId' on string 'config-get'Not sure if I'm doing something wrong here or this is a bug.
Edit:
It works if I use it like this:promiser('config-get', {});Not sure if I'm doing something wrong here or this is a bug
This is on me, being overzealous with the type improvements. Promiser API makes an explicit check for amount of parameters and assigns properties based on it. I missed that, sorry!
I don't want to bother tomayac with preparing yet another build, so I'll just prepare a PR that updates the example and makes sure the types require all required params from now on 😄
The first example in the doc is still not working for me, I went back to using the example types in one of the threads.
I get this in vscode: "Type '(value: any) => void' is not assignable to type 'OnreadyFunction'.
Target signature provides too few arguments. Expected 1 or more, but got 0."And then the other methods are not typed either 😥
Thank you for raising the issue, I have the fix ready! 😄
@tomayac, should we update the README promiser example to v2 style (using promises instead of callbacks)? It's a bit cleaner imo 😄
const initializeSQLite = async () => { try { console.log('Loading and initializing SQLite3 module (v2 promise style)...'); const promiser = await sqlite3Worker1Promiser.v2(); console.log('Done initializing (v2 promise style). Running demo...'); const configResponse = await promiser('config-get', {}); console.log('Running SQLite3 version', configResponse.result.version.libVersion); const openResponse = await promiser('open', { filename: 'file:mydb-v2.sqlite3?vfs=opfs', }); console.log( 'OPFS is available, created persisted database at', openResponse.result.filename.replace(/^file:(.*?)\?vfs=opfs$/, '$1'), ); } catch (err: any) { if (!(err instanceof Error)) { err = new Error(err.result.message || 'Unknown error'); } console.error(err.name, err.message); } };
I'd happily merge a quick PR that does that, yes.
It's strange, in the current version, I have an error indicating that the v2 is not a function, and the default version seem to be the v2 when debugging the code.
Is it normal?
It's strange, in the current version, I have an error indicating that the v2 is not a function
Current version is incorrect. This PR should resolve this, see here: https://github.com/sqlite/sqlite-wasm/pull/160/changes#diff-619cc2239a7eb4ef05041767e6ab0e4fb069e98ee9d2c83c2d8e1865c475e141
@tomayac, could I ask for a new release, please? 😄
Reacted by solodevelopingReleased as https://github.com/sqlite/sqlite-wasm/releases/tag/3.51.2-build9. Thanks for the work on this!
2 remaining items
As of today, worker1Promiser API is considered deprecated and will no longer be supported from our side. Next release will include the
@deprecatedtags to the types as well, but we already removed an example usage of this API, and added a deprecation notice to the README.Just to stress, though: upstream promises to not remove Worker1 for the life of the project. It will be maintained insofar as needed to keep older code working, so will get any necessary bug fixes but no new capabilities. That is: it's safe to continue using it, but... seriously, it's a toy and should not be used for anything but "hello, world" apps.
Is there an intention to provide more examples of such implementation in this project or to provide an extended library implementing this?
Or should it be done elsewhere, like in another project?
Is there an intention to provide more examples of such implementation in this project or to provide an extended library implementing this?
I'd be happy to provide more examples, but are the ones in
/demonot descriptive enough?I mean, it's sufficient, to be fair it does not do much that I could have figured by myself 😊 Even though it's not TS
I suppose that this is not the place for a "real" library?
I will change my code, hopefully I won't encounter too many problems 😊
@solodeveloping, ask and you shall receive 😄
I've opened a PR which modernized the demos a tiny bit. Please let me know if this is what you had in mind 😄
Sorry, I missed the notification somehow.
It does look better.
I think there is an error in the main doc btw, maybe
"new sqlite3.oo1.DB('/mydb.sqlite3', 'ct');" => this is possible only if you have setup a pool no? The other mods seem to require that filename be a special value (":memory:" for instance)
https://sqlite.org/wasm/doc/trunk/api-oo1.md
It's a bit unclear though
"new sqlite3.oo1.DB('/mydb.sqlite3', 'ct');" => this is possible only if you have setup a pool no?
That's legal as-is, but the db is transient, stored in the Emscripten-emulated virtual filesystem. This API has no connection pool. "c" means "create if it doesn't exist" and "t" means "enable the default logging tracer".
It's a bit unclear though
Functionally speaking, in the Emscripten virtual filesystem, there's almost no functional difference between
/foo.dband:memory:because both are transient. The former has a persistent name for the life of the page, though, addressable via multiple connections, or closable/re-openable by a single connection.Okay, thank you 😊
What are the differences between the new method and the Worker1 exactly?
If I do a new web project, I can run some code, same code I can't run from my web extension.
And the old way still works in my extension too.
This gets blocked with the new method:
And it does not in a new project, like I said.
Okay, found it:
I assumed there was no reason for it to fail, and assumed there is a difference:
// creates a bug, orinal version const W = new Worker(new URL("sqlite3-opfs-async-proxy.js", import.meta.url)); // working (like in the Worker1 code): const W = new Worker(new URL("sqlite3-opfs-async-proxy.js", import.meta.url), { type: "module" });
I have a new issue opened at SQLite so I'll add this there.
// working (like in the Worker1 code):
const W = new Worker(new URL("sqlite3-opfs-async-proxy.js", import.meta.url), {
type: "module"
});That JS file is not a module and it must not be loaded directly by any client code. It's an internal detail of the library, not a client-facing part, and will be loaded automatically during initialization of the library if the library detects that OPFS is available.
I'm not sure of what you mean, this is the code as it is in the library.
I'm not sure of what you mean, this is the code as it is in the library.
Then you're looking at an old version.
I'm on "@sqlite.org/sqlite-wasm": "3.51.2-build9", which is the last one on npm too
Yeah, this is the code I find here https://www.npmjs.com/package/@sqlite.org/sqlite-wasm?activeTab=code
And it's the code I find here
sqlite-wasm/src/bin/sqlite3-bundler-friendly.mjs
Line 18095 in a81e4ef
Which I assume becomes "index.mjs", which is the main script ""main": "./dist/index.mjs"," (in package.json)
If there is a change, maybe it's in a dev branch?
Type
Bug Report
Description
Hi,
I still get typing problems in the current version "3.51.2-build7". Trying to import with
import { sqlite3Worker1Promiser } from '@sqlite.org/sqlite-wasm'gives me an error. This should be fixed with #54 Or am I missing something?