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

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.

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

@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.

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

@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.

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.

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.

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.

@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.

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?

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

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.

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

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";

Any update on this?

I am getting Uncaught (in promise) TypeError: LoadLibraryExW failed on running the compiled version with

1. All permission enabled (-A)
2. Using this on Deno v2.2.8

image

Any update on this? 有什么更新吗?

I am getting Uncaught (in promise) TypeError: LoadLibraryExW failed on running the compiled version with我在运行编译版本时得到 Uncaught (in promise) TypeError: LoadLibraryExW failed

1. All permission enabled (-A)已启用所有权限 (-A)
2. Using this on Deno v2.2.8在 Deno v2.2.8 上使用它

image

May I ask if you solved this problem? I'm experiencing the same thing.

@gabrielferguson Not as of writing this. The issue lies with Deno runtime so I opened an issue on Deno & it is now being addressed. The fix for this has been merged with main branch and is supposed to get released with Deno v2.3.0, i.e; mid May'25.

Here is link to the issue: denoland/deno#23266 (comment)

@realChakrawarti Great, looking forward to the new Deno version!

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";

+1 this works for me.

Run deno add npm:@libsql/client and run the script with permission --allow-ffi or --allow-all (-A).

Example script:

import type { Client } from "@libsql/client/node";
import { createClient } from "@libsql/client/node";
if (import.meta.main) {
 const client = createClient({ url: ":memory:" });
 await client.batch(
 [
 "CREATE TABLE movies (title TEXT, year INT, embedding F32_BLOB(3))",
 "CREATE INDEX movies_idx ON movies (libsql_vector_idx(embedding))",
 "INSERT INTO movies (title, year, embedding) VALUES ('Napoleon', 2023, vector32('[1,2,3]')), ('Black Hawk Down', 2001, vector32('[10,11,12]')), ('Gladiator', 2000, vector32('[7,8,9]')), ('Blade Runner', 1982, vector32('[4,5,6]'))",
 ],
 "write"
 );
 const result = await client.execute({
 sql: `
 SELECT m.title, m.year
 FROM vector_top_k('movies_idx', '[4,5,6]', 3) AS v
 JOIN movies AS m ON m.rowid = v.id
 `,
 });
 console.log(result.rows);
 // Clean up (optional, for demonstration purposes)
 await client.execute("DROP TABLE movies");
}

My Deno version:

deno 2.2.12 (stable, release, x86_64-pc-windows-msvc)
v8 13.5.212.10-rusty
typescript 5.7.3

My deno.json:

{
 "imports": {
 "@libsql/client": "npm:@libsql/client@^0.15.4"
 }
}

I'm using Neon while it's being fixed. Deno says it's Turso's fault, and Turso says it's Deno's fault. 😅

@edard3v @gabrielferguson @EthanThatOneKid If you're willing to give it another go, we released a new driver which should have no problems with Deno 🤞🏻

https://turso.tech/blog/introducing-turso-serverless-javascript-driver