Fix Deno packaging and add example to CI

[kj-9]

refs #138

changes:

• add test for Deno to run example script in ci
• allow Deno to use local file or :memory: by simply using lib-esm/node.js instead of ./lib-esm/web.js

enables:

• deno to run on local db file or :memory: as node.js

downside:

• requires --allow-ffi flag to run since lib-esm/node.js imports createClient function from sqlite3

[edard3v]

Sorry bro, I got tired of trying things, if you want I'll leave the repository here, it currently works remotely, but not locally.

https://github.com/edard3v/template-deno

[zephraph]

Yeah, I think this would be nice to see land. An alternative implementation (if we wanted to avoid ffi) would be to use node:sqlite which landed in Deno 2.2.0 and is supported in node as of v22.5.0. Personally I'd prefer just to land this as is though. There are certain cases that restict the ffi usage, but it's the minimal viable change to get a lot of local cases working. This issue is also experienced upstream in drizzle which is where I first encountered it.

[penberg]

Hey @kj-9! Why is this pull request in draft mode?

[kj-9]

@penberg
thanks for taking time. because I wasn't sure if it was a good option, but I'm now removing the draft status.

It'd be awesome if you could take a look at this.

[penberg]

@notrab I am fine with this, please have a look.

[notrab]

@penberg @kj-9 @edard3v @zephraph this looks fine to me, although I did want to check that there could be no unintended side effects by using the node.js entrypoint, but since Deno now has full Node.js compatibility, it should work as is without needing to change any internal import statements?

If there's no pushback from anyone else on this, let's merge and release.

[zephraph]

The imports are fine. The one thing I'm still thinking on is the FFI requirement. At first I was thinking that wouldn't be too big of a deal, but I'm a little more concerned about it because there are certainly usecases (like deno deploy) that this will break for.

[zephraph]

Yeah, so this is unfortunately a breaking change and there's not an easy way I can see to get around it. @kj-9 enumerated some of the challenges in the original issue. If FFI is denied then the module will throw an exception. In existing deployments that rely on it (deno deploy, val.town, etc) that don't (or can't) provide FFI that'll render the module unusable. The ideal case here would be that the web path should still work if FFI isn't enabled. @kj-9 pointed out conditional imports, which would also be a breaking change because it would indeed make createClient async which is a breaking change.

[edard3v]

Greetings! I don't know if I understood correctly. Does it already work locally with Deno? I'm currently on Neon so I haven't tried it. If there's a green light, I might switch.

[notrab]

@zephraph and I spoke briefly about this today. This is considered a breaking change, so @zephraph kindly offered to think through the proposal a bit more and we can see where we end up.

[kj-9]

Hi folks, thanks for the comments!
I feel like this PR isn’t ideal, as @zephraph pointed out—it breaks compatibility with Deno Deploy 😅.
To clarify my thoughts so far, here’s a summary of the options I’ve considered. None of them are perfect though...

1. Requiring FFI (this PR)

• This approach seems not practical since most deployment environments (e.g., Deno Deploy) do not support FFI. (and are unlikely to do so in the future for security reasons?😅)

2. Dynamically Import FFI

• Use dynamic imports to load FFI functions only when needed.
• This would require changing the function signature to async or introducing a separate async
  version like createClientAsync.
• While not ideal, this could be an acceptable solution as it improves usability and makes importing local SQLite functionality more noticeable and accessible.
• However, users would still need to adopt the new function if they want to use it, which takes time and effort to fix downstream tools like drizzle.

3. Use libsql-client-wasm

• Replace the current implementation with a libsql-client-wasm for local SQLite functionality in Deno.
• IMO, this aligns well with Deno’s philosophy of using WASM as the primary interface for external binaries.
• However, the current libsql-wasm-experimental library does not yet provide full functionality (e.g. I tried but batch() does not work properly in the exmaple). It’s also unclear whether it will be fully compatible with libsql-client?

[edard3v]

It's a shame. Well, hopefully one day you can use Turso in Deno. Thanks

[notrab]

It's a shame. Well, hopefully one day you can use Turso in Deno. Thanks

@edard3v you can? Just not local file with the libsql client. Turso works over HTTP, so you should have no problems communicating with Turso using a remote database.

[jsharma44]

I am having same issue. is there a way we can use local db with this SDK in deno. Thanks

[zephraph]

I am having same issue. is there a way we can use local db with this SDK in deno. Thanks

You can directly import the node version: import { createClient } from "npm:@libsql/client/node";