Question: How can I use this package in a library?

[DallasHoff]

I have been trying to figure out how I can use this package as a dependency in a library I am building. The web worker from @sqlite.org/sqlite-wasm creates a second web worker using sqlite3-opfs-async-proxy.js and this is presenting problems when I attempt to bundle my library. I have tried to use Vite, Tsup, Parcel, and Rollup to bundle my library, but I encounter similar issues in each that all stem from the way that this package is structured with that inner worker:

1. When the first worker attempts to construct the inner worker in the app, it tries to fetch sqlite3-opfs-async-proxy.js, but this 404s since it would require the app consuming the library to serve sqlite3-opfs-async-proxy.js themselves.
2. So, if I try to inline the inner worker in the library bundle by converting it to a data URL (new Worker("data:application/javascript;base64,...")), OPFS is not available because the origin in that context is the data URL that my library's worker is inlined as, not the app's origin, and obviously a data URL cannot have the required HTTP headers.

As it stands, I can use @sqlite.org/sqlite-wasm as the direct dependency of an app, but I have been struggling to use it as a dependency of a library. I would really appreciate some guidance.

[steida]

@DallasHoff Check https://github.com/evoluhq/evolu

[sgbeal]

FWIW, the core upstream project is delivered in a form which you can just drop into your project. If @steida's approach isn't suitable for you (i can't judge that, being a complete zero for all things node), the "embed it directly" approach might be.

[DallasHoff]

Interesting, so that library, Evolu, just uses tsc in its build script, basically just outputting the source code sans types. I tested this, and the library now works just fine in an application. The app's builder does the bundling. I wonder if this is a common practice in libraries or if it will cause me problems down the line that I can't do any pre-bundling. Thanks for the point of reference @steida

[steida]

@DallasHoff Yeah. I was also surprised, but it looks like it works well everywhere. Feel free to open an issue in Evolu if not. Thank you.

[Matt-TOTW]

Hi @DallasHoff, am I right to understand that you were able to solve this problem and if so, could you please expand a bit on how you did so?
I believe I am encountering similar issues attempting to include this as part of a library. I was able to use vite's worker handling to inline my outer worker and I can see that it correctly inherited the security context of the app's origin, but the inner worker - the one spawned by sqlite-wasm from sqlite3-opfs-async-proxy.js - does not and so the opfs is unavailable.

[sgbeal]

but the inner worker - the one spawned by sqlite-wasm from sqlite3-opfs-async-proxy.js - does not and so the opfs is unavailable

Be aware that not all browsers supported, until relatively recently, launching a worker from within a worker (IIRC, Firefox only supports that since not quite a year). There was also a Safari ticket for v16.x in which it didn't properly expose the storage APIs in the sub-worker case.

i.e. the problem might (just speculating) be your browser.

[Matt-TOTW]

I didn't realise that was such a new feature however I don't believe that is the problem in my case. I am running the latest chrome and I can see that the inner worker spawns just fine, it just doesn't inherit the security context - ie self.crossOriginIsolated = false.

(window.crossOriginIsolated and self.crossOriginIsolated of the outer worker are both true).