StackBlitz support?

[penberg]

We currently have a @libsql/client-wasm package, which is a drop-in replacement for @libsql/client. Let's talk to the StackBlitz folks if this is sufficient to support libSQL in their environment.

[matthewp]

Pinging @d3lm who works at StackBlitz.

[matthewp]

@d3lm Given that this is a drop-in replacement, is this something that could be set up on your side to be hotswapped?

[d3lm]

Hey all! 👋 Thanks for tagging me. I am happy to help and provide any info that's needed.

[penberg]

Hey @d3lm! What me and @matthewp have been thinking is that the @libsql/client import would be swapped on StackBlitz to @libsql/client-wasm, which has the same API. Is that something that happens on StackBlitz side or do we need to do something on the packaging to make it work?

[d3lm]

Given that @matthewp has forwarded the options I posted on Discord I ll just expand on 1) which was that we list @libsql/client-wasm as a polyfill on our side so it gets installed automatically if someone tried to install @libsql/client.

However, there are some requirements:

• It has to be a drop-in replacement which means that the polyfill has no additional dependencies. Additional dependencies have to be bundled dependencies.
• We have to configure a version range. Ideally the polyfill is released in lock-step with the native version similar to esbuild or swc.

If that's given, then we can surely list it as a polyfill on our end.

[penberg]

Hey @d3lm, it is indeed a drop-in replacement with no additional dependencies and I will release the packages in lock-step so that part is also covered. Please do let me know if there is anything else you need from our side for this. I will keep the issue open for tracking purposes until it's this is working end-to-end. Thanks a lot for the help so far @d3lm!

[d3lm]

Is it already all in place and published?

[d3lm]

Also, from what version do you want to use the polyfill? I also see that there is @libsql/[email protected] which doesn't exist for @libsql/client. It's important that we pick a version and then make sure that it's always released in lock-step.

[penberg]

Hey @d3lm, 0.4.0-pre.10 exists for both under the next tag.

[d3lm]

Yes, but if you did npm i @libsql/client it would use the latest tag and not next. Ideally there's stable versions for latest. I think if that's given I could list it as a polyfill starting from 0.4.0-pre.X.

[penberg]

@d3lm Right, makes sense. Let me work towards releasing 0.4.0 and let's use that as the starting point. I will ping you again when it's out.

[d3lm]

Ok that sounds perfect. I am happy to then list the polyfill. Exciting! 🙌 👏

[d3lm]

Out of curiosity, can libsql replace sqlite3 and did you fully compile a full fledged implementation of SQLite to Wasm?

[penberg]

Hey @d3lm, 0.4.0 is now released.

libSQL is a fork of SQLite so yes there is a full SQLite implementation compiled into Wasm for the @libsql/client-wasm package similar to https://github.com/sqlite/sqlite-wasm

[d3lm]

Very cool! Awesome work @penberg and kudos to shipping 0.4.0 👏

[d3lm]

Something I already noticed is that the polyfill is not a full drop-in replacement IISC. Cause the Wasm depends on @libsql/libsql-wasm-experimental which is not a dependency of the original package @libsql/libsql-client. Also it defines a different version range for @libsql/core. All of that is problematic for a polyfill on our side cause it won't pick up those changes especially the extra dependency. So if that Wasm depends on that extra dependency it has to be published with it without relying on the package manager to install it.

[d3lm]

Also, removing dependencies is fine in the polyfill, like libsql, but that still means libsql will be installed cause it's part of the original package.

[penberg]

@d3lm #167 should hopefully cure the wasm dependency issue. Will fix the core dependency version when I publish a new version.

[penberg]

There were various things that needed fixing but as of 9decdd5 it's working now.

[d3lm]

Awesome work!