`sqlite3-bundler-friendly.mjs` missing [3.51.1-build2]

[robingenz]

We have just updated our project from version 3.50.3-build1 to version 3.51.1-build2. Unfortunately, in version 3.51.1-build2, the following import in sqlite3-worker1-bundler-friendly.mjs is broken because sqlite3-bundler-friendly.mjs is no longer shipped:

import { default as sqlite3InitModule } from './sqlite3-bundler-friendly.mjs';
sqlite3InitModule().then((sqlite3) => sqlite3.initWorker1API());

3.50.3-build1	3.51.1-build2

[tomayac]

This happened earlier already with the release of 3.50.4: 3.50.4-build1...main#:~:text=Update%20paths%20in%20index.mjs%20to%20remove%20*%2Dbunder%2Dfriendly. It seems like a simple rename would work to fix it.

[rblank]

I've hit this as well. A few comments:

• 3.50.4-build1 works fine; 3.51.0 and above are broken.
• It looks like a rename was done in 0c48c20, but reverted just afterward in a8bbbc1.
• I don't understand how upstream was generating sqlite3-bundler-friendly.mjs before, but the new code doesn't seem to do it. So something must be missing there.
• I tried using sqlite3-worker1.mjs instead of sqlite3-worker1-bundler-friendly.mjs, but the former is currently broken. In particular, this line doesn't make any sense, as it's a top-level return in a JS module, which is a syntax error. It looks like a copy-paste mistake between sqlite3-worker1-promiser.c-pp.js‎ and sqlite3-worker1.c-pp.js, and the line should probably look like the following instead:

  import {default as sqlite3InitModule} from './sqlite3.mjs';

It's not clear to me if renaming is the correct fix, or if the makefile should be fixed to generate sqlite3-bundler-friendly.mjs again. I'm happy to provide a patch, but I need some guidance. Mentioning @sgbeal as the author of the commit that introduced the issue.

[rblank]

I can confirm that fixing sqlite3-worker1.mjs as described above makes it work as expected.

[sgbeal]

The sqlite3-worker.mjs breakage is resolved with https://sqlite.org/src/info/11f5ab0dd8. As @rblank points out, there was a serious copy/paste and/or bad-hair-day error which broke the ESM build for that file. That file was formerly untested, but is now used by one of our test pages to keep that from happening again.

As far as the bundler-friendly file availability goes: We would really like to keep that out of the distribution tarball because (A) it's huge and (B) it's only used by node-based toolchains, and those environments invariably use the npm package (as opposed to the distribution tarball). i'm still catching up on what changes need to be made before the 3.52 release, so can't currently say what the state of the bundler-friendly file availability is, but we don't currently plan on including those files in 3.52.

[jurerotar]

Thank you for the heads up on the expected changes in 3.52! I'm happy to dig in a bit and try to figure out if there's anything specific inside bundler-friendly file that we couldn't just patch in during the build process of this package 😄

[jurerotar]

@robingenz, @rblank, I've prepared a pull request which reworks the build process a tiny bit and should resolve this issue as a result. Would you be so kind to pull the branch and try it out locally to see if everything works as expected for your use-cases? Because it's such a large rework, I'd love to get a bit more confirmation that I hadn't missed anything 😄

You just need to pull the branch, run tsdown to generate /dist, run npm i "../path-to-cloned-package" and you should be good to go 😄