sqlite-wasm sqlite-wasm/jswasm/sqlite3-node.mjs does not exist

so import under nodejs fails, even if not used.

Nov 10 '25 17:11 singpolyma

This project supports only browser deployments, not node. The canonical tree can build node builds but they are 100% untested beyond for compilability and we do not publish such builds.

Nov 10 '25 19:11 sgbeal

Should https://github.com/sqlite/sqlite-wasm/blob/main/node.mjs be removed then since it references a file that does not exist?

Nov 10 '25 19:11 singpolyma

That's up to @tomayac - he decides what goes into this tree. The upstream tree, however, very specifically does not, and has no plans to, support node.

Nov 10 '25 19:11 sgbeal

@sgbeal I will say that 3.51.0 was a bit of a surprise. Several files changed names or disappeared, see https://github.com/sqlite/sqlite-wasm/commit/0c48c20757d1a39d64bc30de964d1c3071df1e6b for some changes that I needed to make. One of the missing files, which definitely was still there in 3.50.0, is jswasm/sqlite3-node.mjs. Could you check if those file name changes and the removal were on purpose?

Nov 11 '25 03:11 tomayac

The nodes builds are part of the build process, but they were never intended to be one of our deliverables. You are are course free to include them here but i'm adamant about not going down the rabbit hole of node support myself. "make b-node" from the ext/wasm dir will include them:

[🍟 jswasm/node/sqlite3-node.js]: ⏳ building ... [🍟 jswasm/node/sqlite3-node.js]: 🔥🔥🔥Unsupported build: use at your own risk! [🍟 jswasm/node/sqlite3-node.js]: 🐞 Fragile workaround for emscripten/issues/18237. See b.call.patch-export-default. [🍟 ./jswasm/node/sqlite3-node.wasm] 💈 wasm-strip [🍟 ./jswasm/node/sqlite3-node.wasm] 🧼 /home/stephan/src/emsdk/upstream/bin/wasm-opt [🍟 jswasm/node/sqlite3-node.js]: 🐞 (disabled because it breaks emsdk 4.0.16+) [🍟 jswasm/node/sqlite3-node.js]: 💾 jswasm/node/sqlite3-node.js ==> ./jswasm [🍟 jswasm/node/sqlite3-node.js]: 💾 jswasm/node/sqlite3-node.wasm ==> ./jswasm [🍟 jswasm/node/sqlite3-node.js]: ✅ done! 🔥🔥🔥Unsupported build: use at your own risk!

see https://github.com/sqlite/sqlite-wasm/commit/0c48c20757d1a39d64bc30de964d1c3071df1e6b for some changes that I needed to make

Ah, the bundler-friendly one i'd forgotten about (it falls into the category for node/npm because only node-based tools use them). That file has historically been an unfortunate necessary evil. It was byte-for-byte identical to sqlite3.mjs but our build process had no good way to deal with multiple builds having identical JS/WASM results but different resulting filenames (like "bundler-friendly"). The build recently leveled up and now differentiates between intermediary builds and the final deliverables[^1]. It post-processes the intermediary builds to filter out the pieces which have identical JS/WASM content to the canonical builds (but different names, like "bundler-friendly"), and replaces the appropriate names in their Emscripten-generated module.

[^1]: Which also allows it to run in parallel, which it couldn't effectively do before. "make -j4" of 8 separate builds now runs faster than the 3 or 4 builds we had before. That's also why the emoji were added - to help my eyes separate them during parallel builds.

Nov 11 '25 06:11 sgbeal

The nodes builds are part of the build process, but they were never intended to be one of our deliverables.

I download the zip from https://sqlite.org/download.html, and the sqlite3-node.js file used to be part of it. Could you make it part of the .zip again? I never made any changes to the files I get from your server, just provide a thin wrapper around them, so npm is happy.

Nov 11 '25 07:11 tomayac

and the sqlite3-node.js file used to be part of it. Could you make it part of the .zip again?

It wasn't supposed to have been there (my fault!) and has never been supported or tested. Distributing it gives people the notion that it's supported, but we literally don't even test that build beyond "it compiles" and the first time it doesn't build it will get turned off rather than fix it. Thus i'm truly hesitant to re-add it but will reconsider it.

Nov 11 '25 09:11 sgbeal

I think people understand that Node.js support is best-effort at best, and no one has complained so far about the way it did work, but people have complained about the missing file, so if this helps you make a decision, I'd also vouch for you to add the file back.

Nov 11 '25 12:11 tomayac

Ouch! I also depend on that missing file, which blocks upgrading to the latest version of SQLite.

Nov 12 '25 12:11 jlarmstrongiv

... but people have complained about the missing file, so if this helps you make a decision, I'd also vouch for you to add the file back.

Fair point. i'll give in. But to have said it again:

NO WARRANTIES! It MIGHT NOT EVEN LOAD. It will NEVER SUPPORT OPFS!

Nov 12 '25 16:11 sgbeal

Thank you, @sgbeal. Let me know when the file is back, and I will create a new build.

Nov 13 '25 01:11 tomayac

After having done this: i'm having second thoughts. Re-adding this one, 100% unsupported, untested file adds 425k to our distribution bundle for everyone else, and that's very difficult to justify.

What if, instead, we add a new build target which does all the stuff which 'all' and 'dist' do but also includes the node target?

Nov 13 '25 08:11 sgbeal

As long as I can somehow automate the npm releases (as in: script them, with human oversight), I'm fine. You could maybe add a new download option to the site, so people can choose what .zip they download, the one with or without Node.js (non-official-)support.

Nov 13 '25 13:11 tomayac

As long as I can somehow automate the npm releases (as in: script them, with human oversight), I'm fine.

i'll add automation for this in the next day or so and post back here.

You could maybe add a new download option to the site, so people can choose what .zip they download, the one with or without Node.js (non-official-)support.

That'd be a step too far for a build we claim to not support. Our release checklists have plenty to do - we don't really want more deliverables, especially for something we don't actively support[^1]. That's part of the reason we don't yet host 64-bit builds.

[^1]: the irony of saying that while also being here supporting it is not lost on me.

Nov 13 '25 14:11 sgbeal

i'll add automation for this in the next day or so and post back here.

It turns out that the build can already do this:

$ ./configure
$ make sqlite3.c
$ cd ext/wasm
$ make -j4
$ make b-node

That extra make invocation for b-node is currently a workaround for a makefile deps problem which might be fixed by the time you read this, but the above will work with the 3.51.0 release.

Edit: that's now fixed in the trunk: only a single make is needed. The file you want is jswasm/sqlite3-node.mjs. The 3.51.0 bundle might also have a sqlite3-node.wasm but you shouldn't need that: the mjs file "should" (and, in the trunk, does) get filtered to use sqlite3.wasm instead because those builds produce identical .wasm files.

Nov 14 '25 14:11 sgbeal

That's great, @sgbeal. I just downloaded the current release again from the website, but I don't see the new file re-added yet. Will you update the current version to include it, or should folks wait for the next proper release? Either is fine with me.

Nov 17 '25 00:11 tomayac

I just downloaded the current release again from the website

You'll need to do an explicit "make b-node". That deliverable is not built by default. Just tested with the 3.51 branch:

$ make b-node emcc_opt=-Oz; # without -Oz the wasm file will be huge
...
$ ls -lad jswasm/*node*
drwxrwxr-x 2 stephan stephan   4096 Nov 17 12:51 jswasm/node
-rw-rw-r-- 1 stephan stephan 612191 Nov 17 12:51 jswasm/sqlite3-node.js
-rw-rw-r-- 1 stephan stephan 851492 Nov 17 12:51 jswasm/sqlite3-node.wasm

Caveat: that version has the slight problem that the node build uses its own .wasm file instead of sqlite3.wasm:

$ grep "'sqlite3.wasm'" jswasm/sqlite3-node.js
$ grep "'sqlite3-node.wasm'" jswasm/sqlite3-node.js
  return locateFile('sqlite3-node.wasm');
    wasmFilename: 'sqlite3-node.wasm' /* replaced by the build process */

That's only a "problem" in that sqlite3-node.wasm is byte-for-byte identical to sqlite3.wasm, so it's superfluous. The trunk build replaces 'sqlite3-node.wasm' with 'sqlite3.wasm' in sqlite3-node.js.

Apropos .js...

3.51 apparently incorrectly builds node as vanilla JS, not ESM, so it probably won't work in node at all. The trunk was recently patched to (again) build that one in ESM mode. That flag got lost during the recent build rework to support 64-bit builds.

Nov 17 '25 12:11 sgbeal

I don't really want to be in the business of building SQLite just for adding unsupported Node.js support 🙃. Apart from that, it wouldn't work, but I admittedly have no idea how this is supposed to work and didn't dig much. Here's what I tried:

./configure
# This ran through without error
make b-node emcc_opt=-Oz;
# This failed with:
# make: *** No rule to make target `b-node'.  Stop.

Nov 18 '25 05:11 tomayac

I don't really want to be in the business of building SQLite just for adding unsupported Node.js support 🙃.

Precisely my position :).

make b-node emcc_opt=-Oz;

My apologies, that needs to be done from the ext/wasm dir, which has an almost-standalone build process.

Nov 18 '25 23:11 sgbeal

I'm trying this now, but it still fails. I have emcc installed:

$ emcc --version
shared:INFO: (Emscripten: Running sanity checks)
emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.20-git
Copyright (C) 2025 the Emscripten authors (see AUTHORS.txt)
This is free and open source software under the MIT license.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

I rerun configure:

$ make clean
# Cleaning confirmed
$ ./configure
# Long output, no errors

But it still seems to fail:

$ pwd
/Users/tsteiner/Downloads/sqlite-src-3510000/ext/wasm
$  make b-node emcc_opt=-Oz;
GNUmakefile:103: *** Missing config.make. It gets generated by the configure script if the EMSDK is found.  Stop.

Nov 19 '25 11:11 tomayac

First of all, congratulations on this work! I recently started using it in a new project and it works perfectly.

I also missed the node file. Even though it doesn't have first-rate support, I imagine it's useful for memory testing, etc. 🙂

Nov 19 '25 18:11 hiukky

Hi, can't get this lib to work for a client-side DB in a SvelteKit app. I'm running into this exact issue. Any tips on resolving it? Thanks!

Nov 19 '25 21:11 developerzeke

I'm trying this now, but it still fails. I have emcc installed:

$ emcc --version shared:INFO: (Emscripten: Running sanity checks) emcc (Emscripten gcc/clang-like replacement + linker emulating GNU ld) 4.0.20-git Copyright (C) 2025 the Emscripten authors (see AUTHORS.txt) This is free and open source software under the MIT license. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I rerun configure:

$ make clean

Cleaning confirmed

$ ./configure

Long output, no errors

But it still seems to fail:

$ pwd /Users/tsteiner/Downloads/sqlite-src-3510000/ext/wasm $ make b-node emcc_opt=-Oz; GNUmakefile:103: *** Missing config.make. It gets generated by the configure script if the EMSDK is found. Stop.

@tomayac I was able to compile here with the same flags.

sqlite/ext/wasm on  master [?] via C v13.3.0-gcc via  v24.6.0 
❯ make b-node emcc_opt=-Oz
using emcc version [4.0.20]
==============================================================
== Development build. Make one of (dist, snapshot) for a
== smaller and faster release build.
==============================================================
🔇 Eliding loud build info. Pass loud=1 to enable it.
cc -O0 -g -std=c99 -o mkwasmbuilds mkwasmbuilds.c -DWASM_CUSTOM_INSTANTIATE=1
./mkwasmbuilds > .wasmbuilds.make
using emcc version [4.0.20]
==============================================================
== Development build. Make one of (dist, snapshot) for a
== smaller and faster release build.
==============================================================
🔇 Eliding loud build info. Pass loud=1 to enable it.
[🍦]: Setting up target b-vanilla
[🍨]: Setting up target b-vanilla64
[🍬]: Setting up target b-esm
[🍫]: Setting up target b-esm64
[👛]: Setting up target b-bundler
[📦]: Setting up target b-bundler64
[🛼]: Setting up target b-speedtest1
[🛼64]: Setting up target b-speedtest164
[🍟]: Setting up target b-node
[🍔]: Setting up target b-node64
[💿]: Setting up target b-wasmfs
[💿]: 🛑 disabled by condition: ifeq (1,0)
[🎻]: Setting up target b-fiddle
[🎻🐞]: Setting up target b-fiddle.debug
cc -O0 -o c-pp-lite c-pp-lite.c ../../sqlite3.c '-DCMPP_DEFAULT_DELIM="//#"' -I../.. \
        -DSQLITE_OMIT_LOAD_EXTENSION -DSQLITE_OMIT_DEPRECATED -DSQLITE_OMIT_UTF16 \
        -DSQLITE_OMIT_SHARED_CACHE -DSQLITE_OMIT_WAL -DSQLITE_THREADSAFE=0 \
        -DSQLITE_TEMP_STORE=3
[💾 bld/EXPORTED_FUNCTIONS.api] 💾🔒[ ./bld/EXPORTED_FUNCTIONS.api]
cc -o version-info -I../..// ../../tool/version-info.c
[bld/sqlite3-license-version.js] 💾
[bld/sqlite3-api-build-version.js] 💾
[🍟 bld/sqlite3-api.node.js]: 💾🔒[./bld/sqlite3-api.node.js] -Dtarget:node -Dtarget:es6-module -Dtarget:es6-bundler-friendly -Dunsupported-build
[🍟 bld/post-js.node.js]: 💾🔒[./bld/post-js.node.js] -Dtarget:node -Dtarget:es6-module -Dtarget:es6-bundler-friendly -Dunsupported-build
[🍟 bld/extern-post-js.node.js]: 💾🔒[./bld/extern-post-js.node.js] -Dtarget:node -Dtarget:es6-module -Dtarget:es6-bundler-friendly -Dunsupported-build --@policy=error -Dsqlite3.wasm=sqlite3-node.wasm
[🍦 bld/sqlite3-api.vanilla.js]: 💾🔒[./bld/sqlite3-api.vanilla.js]
[🍦 bld/post-js.vanilla.js]: 💾🔒[./bld/post-js.vanilla.js]
[🍦 bld/extern-post-js.vanilla.js]: 💾🔒[./bld/extern-post-js.vanilla.js] --@policy=error -Dsqlite3.wasm=sqlite3.wasm
[🍦 bld/pre-js.vanilla.js]: 💾🔒[./bld/pre-js.vanilla.js] -DModule.instantiateWasm
[💾 jswasm/sqlite3-worker1.js] 💾🔒[ ./jswasm/sqlite3-worker1.js]
[💾 jswasm/sqlite3-worker1.mjs] 💾🔒[ ./jswasm/sqlite3-worker1.mjs] -Dtarget:es6-module
[💾 jswasm/sqlite3-worker1-bundler-friendly.mjs] 💾🔒[ ./jswasm/sqlite3-worker1-bundler-friendly.mjs] -Dtarget:es6-module -Dtarget:es6-bundler-friendly
[💾 jswasm/sqlite3-worker1-promiser.js] 💾🔒[ ./jswasm/sqlite3-worker1-promiser.js]
[💾 jswasm/sqlite3-worker1-promiser.mjs] 💾🔒[ ./jswasm/sqlite3-worker1-promiser.mjs] -Dtarget:es6-module
[💾 jswasm/sqlite3-worker1-promiser-bundler-friendly.mjs] 💾🔒[ ./jswasm/sqlite3-worker1-promiser-bundler-friendly.mjs] -Dtarget:es6-module -Dtarget:es6-bundler-friendly
[jswasm/sqlite3-opfs-async-proxy.js] 💾 api/sqlite3-opfs-async-proxy.js ==> jswasm/sqlite3-opfs-async-proxy.js
[🍦 jswasm/vanilla/sqlite3.js]: ⏳ building ...
[🍦 ./jswasm/vanilla/sqlite3.wasm] 💈 wasm-strip
[🍦 ./jswasm/vanilla/sqlite3.wasm] 🧼 /home/hiukky/develop/sqlite/emsdk/upstream/bin/wasm-opt
[🍦 jswasm/vanilla/sqlite3.js]: 🗑 Stripping export wrappers.
[🍦 jswasm/vanilla/sqlite3.js]: 💾 jswasm/vanilla/sqlite3.js ==> ./jswasm
[🍦 jswasm/vanilla/sqlite3.js]: 💾 jswasm/vanilla/sqlite3.wasm ==> ./jswasm
[🍦 jswasm/vanilla/sqlite3.js]: ✅ done!
[🍟 bld/pre-js.node.js]: 💾🔒[./bld/pre-js.node.js] -Dtarget:node -Dtarget:es6-module -Dtarget:es6-bundler-friendly -Dunsupported-build -DModule.instantiateWasm
[🍟 jswasm/node/sqlite3-node.mjs]: ⏳ building ...
[🍟 jswasm/node/sqlite3-node.mjs]: 🔥🔥🔥Unsupported build: use at your own risk!
[🍟 jswasm/node/sqlite3-node.mjs]: 🐞 Fragile workaround for emscripten/issues/18237. See b.call.patch-export-default.
[🍟 ./jswasm/node/sqlite3-node.wasm] 💈 wasm-strip
[🍟 ./jswasm/node/sqlite3-node.wasm] 🧼 /home/hiukky/develop/sqlite/emsdk/upstream/bin/wasm-opt
[🍟 jswasm/node/sqlite3-node.mjs]: 🗑 Stripping export wrappers.
[🍟 jswasm/node/sqlite3-node.mjs]: 💾 s/"sqlite3-node.wasm"/"sqlite3.wasm"/g in ./jswasm/sqlite3-node.mjs
[🍟 jswasm/node/sqlite3-node.mjs]: ✅ done! 🔥🔥🔥Unsupported build: use at your own risk!

sqlite/ext/wasm on  master [?] via C v13.3.0-gcc via  v24.6.0 took 36s

Nov 20 '25 01:11 hiukky

@sgbeal, any idea where the EMSDK detection could fail? I have emscripten installed via brew on my Mac and it’s working as per the emcc --version check.

Nov 20 '25 05:11 tomayac

With my apologies for the delayed responses...

I also missed the node file. Even though it doesn't have first-rate support, I imagine it's useful for memory testing, etc. 🙂

(...snip and interweave some quotes with a recurring theme...)

Hi, can't get this lib to work for a client-side DB in a SvelteKit app. I'm running into this exact issue. Any tips on resolving it?

My suggestion, as the one who created the contested build in question, is to use a made-for-node SQLite binding, not this one. To stress:

The upstream SQLite project does not guaranty any stability of either the availability nor the functionality of any node-specific builds

Those are fundamental properties of "unsupported". The recently-added pile of 🔥 its build emits is intended to scare y'all away, not entice further use.

The made-for-node bindings provided elsewhere do provide such guarantees and they don't include 🔥 in their build output

Why we so adamant about this:

Nobody in the upstream project uses node in any capacity nor do they have any reason to, so we collectively lack the topical expertise, the topical interest, and any motivation to gain either. We all have other proverbial fish to fry.
To avoid stepping on any toes of node's well-established SQLite bindings. Those are inarguably a superior fit for node and our encroachment would be to the detriment of node users. As end users we collectively tend to prefer "official" solutions over "unofficial" ones, and this project sidesteps perceived toe-stepping by not offering an "official" solution for node.
The node build was added just to see if it would build, which i long-since regret doing because the pressure to continue doing so comes back squarely on an adamantly reluctant me. The past year i've read a grand total of two reports that someone tried it and, frankly, two users trying something out is not enough to justify my volunteering to bring node into my set of Lifestyle Choices and maintain that on a day-to-day basis for the rest of my natural life. (The project as a whole gets that level of commitment, necessitating my being selective about which long-term burdens, both in the project and out, go onto my proverbial plate.)

any idea where the EMSDK detection could fail?

That logic is all in:

https://sqlite.org/src/file?name=autosetup%2Fsqlite-config.tcl&ln=1006-1042

In short, it looks for the EMSDK_HOME env var or the directory named in --with-esmdk=/dir. (Reminder to self: go over that check again. Why is it asserting that EMSDK_HOME is not empty and why does that not (inappropriately) kill more builds?)

/Users/tsteiner/Downloads/sqlite-src-3510000/ext/wasm
$  make b-node emcc_opt=-Oz;
GNUmakefile:103: *** Missing config.make. It gets generated by the configure script if the EMSDK is found.

That puzzles me, assuming that configure said something like "Emscripten SDK? /home/stephan/src/emsdk". If it didn't say that, then that error is expected. ext/wasm needs to know where certain binaries are and those are only written if that step says it found emsdk in my home dir (it's might also work for your home dir, but i've never tested that ;)).

I have emscripten installed via brew on my Mac and it’s working as per the emcc --version check.

You're running 4.0.20, so this doesn't apply here, but i'll note it for the others following along:

It will need a relatively recent Emscripten - it may not work anymore on anything less that 4.0.16. Emscripten has always been a moving target and we occasionally have to adjust the build for its behavior changes.

It also needs wasm-strip 1.0.36 or newer (35 might work but 34 won't).

Aside from that:

installed via brew on my Mac

The JS builds are only known to work on Linux. As the build in itself is not a deliverable (as such) we make no efforts to make it portable beyond our own development and release-generation environments.

That is to say: it might work there, might not. It's "unsupported".

I'm trying this now, but it still fails. I have emcc installed:

I was able to compile here with the same flags.

It is very possible that the last release won't build a working node build. If it works, it's a fluke - it was, as part of build refactoring, inadvertently un-tagged as being ESM, and i've no clue how that affects the node build. That's been patched in the trunk.

Nov 20 '25 14:11 sgbeal

Hi, can't get this lib to work for a client-side DB in a SvelteKit app. I'm running into this exact issue. Any tips on resolving it?

My suggestion, as the one who created the contested build in question, is to use a made-for-node SQLite binding, not this one.

@sgbeal I believe this comment was misunderstood. It's not asking for improved Node support. It is saying that since the sqlite-wasm package declares an export for node, but that export points to a non-existent file, apps with server-side rendering enabled will fail to build even if the app only uses the client-side bindings. This is because the builder will check the import in Node.js when building the server-side part of the app and fail the build when it fails to find the file.

This is the same issue the OP was pointing out. This issue was not originally about improving Node support. It was about fixing an issue blocking people from using the browser bindings.

Because of issues like this, it might be better to declare the node binding at a subpath export like @sqlite.org/sqlite-wasm/node rather than exporting it from the package's main export. As you keep saying, the Node build is not supported, so we should have to import it explicitly rather than accidentally import it implicitly.

Nov 20 '25 20:11 DallasHoff

@DallasHoff I ended up using your SQLocal package instead, it's much simpler and does exactly what I need :)

Nov 20 '25 21:11 developerzeke

The wasm version works well with workers on the web. For those looking for an alternative to node, I think the official module in the latest versions is quite stable.

https://nodejs.org/api/sqlite.html

I'm doing some testing. Even though I've been a NodeJs user for a long time, I was unaware of this module.

Nov 20 '25 21:11 hiukky

Because of issues like this, it might be better to declare the node binding at a subpath export like @sqlite.org/sqlite-wasm/node rather than exporting it from the package's main export

The big reason I use sqlite-wasm in my projects in both the browser and nodejs is so that I can use the same code everywhere. The challenge in using other, more established bindings is that there are subtle differences in how they work, while the wasm version has identical behavior in all environments—browser, nodejs, web worker, testing, etc. It’s important to keep the exports field for that compatibility. In a perfect world, the minimal support of nodejs would continue as-is, with the additional build step to generate that file.

Nov 20 '25 22:11 jlarmstrongiv

After spelunking around in the README.md file, I managed to solve my emcc shenanigans by putting an empty emsdk_env.sh file in /opt/homebrew/bin where brew has installed emcc 🤷. Whatever works I guess…

I then managed to create an ESM build using the following commands:

cd ext/wasm
make clean
make b-node emcc_opt="-s ENVIRONMENT=node -s EXPORT_ES6=1 -Oz"

I then tried to use this new file with the existing demo, but it failed:

🧑‍💻 tsteiner in 📂 ~/Documents/javascript/sqlite-wasm on 🌿 main $ npm run start:node

> @sqlite.org/[email protected] start:node
> cd demo && node node.mjs

Loading and initializing SQLite3 module...
node:internal/deps/undici/undici:15845
      Error.captureStackTrace(err);
            ^

TypeError: fetch failed
    at node:internal/deps/undici/undici:15845:13 {
  [cause]: Error: not implemented... yet...
      at makeNetworkError (node:internal/deps/undici/undici:10147:35)
      at schemeFetch (node:internal/deps/undici/undici:11685:34)
      at mainFetch (node:internal/deps/undici/undici:11533:30)
      at fetching (node:internal/deps/undici/undici:11502:7)
      at fetch (node:internal/deps/undici/undici:11368:20)
      at fetch (node:internal/deps/undici/undici:15843:10)
      at fetch (node:internal/bootstrap/web/exposed-window-or-worker:83:12)
      at wfetch (file:///Users/tsteiner/Documents/javascript/sqlite-wasm/sqlite-wasm/jswasm/sqlite3-node.js:151:24)
      at file:///Users/tsteiner/Documents/javascript/sqlite-wasm/sqlite-wasm/jswasm/sqlite3-node.js:160:33
      at Object.callee (file:///Users/tsteiner/Documents/javascript/sqlite-wasm/sqlite-wasm/jswasm/sqlite3-node.js:167:12)
}

Node.js v25.2.1

The sqlite3-node.js file is attached here in case anyone wants to mess around. I have just copied the existing sqlite3.wasm file to a new file sqlite3-node.wasm as they should be identical.

The failing line is 151:

const wfetch = ()=>fetch(uri, {credentials: 'same-origin'});

The uri looks correct to me (file:///Users/tsteiner/Documents/javascript/sqlite-wasm/sqlite-wasm/jswasm/sqlite3-node.wasm on my machine, the double sqlite-wasm/ is correct)…

Nov 27 '25 12:11 tomayac