Is this the right place to request features? Anyway, while S is probably useful, it would be great if it could be disabled. Thank you

Is this the right place to request features?

It is.

Anyway, while S is probably useful, it would be great if it could be disabled

The global S should only be enabled in localhost mode. Are you seeing it elsewhere? There's no really strong argument against removing it from the core, instead requiring each app to export it if they want.

I am asking for this feature because my library embeds Sqlite WASM, and I don't want to confuse users with this console.log.

I am asking for this feature because my library embeds Sqlite WASM,

Fair enough. i'll get it removed in the next day or two.

Thank you :-)

"Ignoring inability to install OPFS sqlite3_vfs:"

Another console.warn I would rather not show it to users of my library. I suppose only real, unavoidable errors should be shown. For debugging, I suppose there can be some location query parameter like "?enable_sqlite_warnings" or explicit dev build. What do you think?

"Ignoring inability to install OPFS sqlite3_vfs:" ... What do you think?

i'm torn on that one primarily because of the support overhead i will have for not having that output to refer to when people post here saying "my OPFS doesn't work" (that has been the single most-posted query about js/wasm to date).

i agree wholeheartedly with you that the library should be silent when being embedded within another layer of library but we also need a way for folks to easily tell why OPFS is not loading for them. Providing a URL argument to enable that still requires a round-trip to the forum where someone will post "it doesn't work" and i'll have to answer "try again with param so-and-so, added here, here, or here, depending on how you're loading it..." (Let's face it - most people don't read the docs!)

There is a "back door" in place for feeding in configuration options, which we "could" use for this. Would the following be too onerous for your particular case?

self.sqlite3ApiConfig = {silent: true};
import sqlite3 ....;
const sqlite3 = await sqlite3ApiInit();

That's hypothetical code - the "silent" flag is not implemented but the bootstrap function does look for a global named sqlite3ApiConfig as a way to slip it config options during the loading/bootstrapping phase. i.e. this would be a simple way to implement this, in particular if the above is hidden from your clients.

:-?

The approach I would use is to make API explicit. So instead of warnings, I would explicitly throw an error when a developer tries to make an impossible instance - new sqlite3.oo1.OpfsDb("/evolu/evolu1.db", "c")

Then throwing an error with an explanation makes sense to me.

My library chooses OPFS/localStorage explicitly by navigator.userAgentData so I can control when I enable the OPFS version.

Thank you. Could you please make a prerelease so that I can test the changes?

Could you please make a prerelease so that I can test the changes?

A snapshot was just uploaded: wasm:/uv/snapshot.html

Uncaught ReferenceError: sqlite3 is not defined at installAsyncProxy (sqlite3-opfs-async-proxy.js?c676:74:12) at eval (sqlite3-opfs-async-proxy.js?c676:878:5) at ../../packages/evolu/dist/sqlite/sqlite3-opfs-async-proxy.js (packages_evolu_dist_sqlite_sqlite3-opfs-async-proxy_js.js:20:1) at options.factory (packages_evolu_dist_sqlite_sqlite3-opfs-async-proxy_js.js:541:31) at webpack_require (packages_evolu_dist_sqlite_sqlite3-opfs-async-proxy_js.js:50:33)

I recommend Next.js for testing https://nextjs.org/docs/getting-started

(sqlite3-opfs-async-proxy.js?c676:74:12) at eval (sqlite3-opfs-async-proxy.js?c676:878:5) at

Stupid user error on my part - will be resolved when i'm back on a computer. That file runs in a dedicated worker and doesn't have access to the sqlite3 object.

That file runs in a dedicated worker and doesn't have access to the sqlite3 object.

That's been corrected and a new snapshot uploaded. That particular file still can use console.debug/warn/error but "shouldn't" ever do so unless its verbosity level is increased via an explicit URL argument.

For some reason, I still see those warnings when I'm using LocalStorage.

For some reason, I still see those warnings when I'm using LocalStorage.

Can you post the exact message? The one about installing the global "S" was moved from the library into the main test app, so it should only be showing up there.

PS: thanks for the FF/Safari updates.

Run https://www.evolu.dev/ in Firefox or Safari.

It shows: Ignoring inability to install OPFS sqlite3_vfs: The OPFS sqlite3_vfs cannot run in the main thread because it requires Atomics.wait().

It shows: Ignoring inability to install OPFS sqlite3_vfs: The OPFS sqlite3_vfs cannot run in the main thread because it requires Atomics.wait().

Good morning,

That one is covered by the new ability to override the warn/debug output routines before the library is ititialized. If you'll do this before your "import", all such messages will go away:

    self.sqlite3ApiConfig = {
      debug: ()=>{},
      log: ()=>{},
      warn: ()=>{},
      error: ()=>{}
    }

This was just tested on Firefox, and the above addition silences any and all debug/warning/error output emitted by the library-level code (as opposed to test app code).

After the import you can delete self.sqlite3ApiConfig - it's only evaluated (and any parts which are needed are copied) during the initial code import and bootstrapping process.

Though i'm 100% willing to remove almost all forms of warning output from the lib by default, the various "cannot load the OPFS VFS for reason so-and-so" warnings exist to reduce the support burden and back-and-forth here in the forum, as "why doesn't my OPFS work?" has been the single most-asked question so far and seems likely to remain so. The output overrides demonstrated above are the current compromise for that.

Thank you, that works.