Create npm repo with all API enabled

[vdshb]

It looks like @sqlite.org/sqlite-wasm artifact does'n support functions ailable under SQLITE_ENABLE_COLUMN_METADATA flag, even though they are marked as supported in wasm documentation.

I suspect, something similar might take place with other non-core API available under different flags.

This is a proposal to create an additional repository (named like @sqlite.org/sqlite-wasm-full, @sqlite.org/sqlite-wasm-all or @sqlite.org/sqlite-wasm-huge) without checking bundle size, but with maximum amount of API enabled and maximum number of flags activated. It might drastically simplify library adoption. I currently implementing kotlin wrapper for sqlite/sqlite-wasm, and it would be a big helper.

[jurerotar]

I was actually working on a feature that would solve your issue!
I've played around with the concept of "custom builds". These custom builds would be fully customizable, but would not be a part of this package (you'd have to fork it, but wouldn't have to touch any code, outside of your required flags).

My draft version is available here.

@sgbeal, would something like this be possible to implement? I've tried passing flags to make command, although without luck.

[sgbeal]

It looks like @sqlite.org/sqlite-wasm artifact does'n support functions ailable under SQLITE_ENABLE_COLUMN_METADATA flag, even though they are marked as supported in wasm documentation.

i've just confirmed that the following functions from that page are in both the canonical wasm and JS files:

• sqlite3_column_origin_name()
• sqlite3_column_table_name()
• sqlite3_column_database_name()

i can only speculate as to what "doesn't support" means here.

would something like this be possible to implement?

The canonical tree supports various tweaks for custom builds. There's not full customization, but certain features can be disabled or enabled that way. That has to be done at build-time, though, so it could only be done in this tree if the whole build is copied over (which y'all are welcome to do, but i can't promise to be able to support a second copy doing its own thing), or a new process is invented for it.

[vdshb]

i can only speculate as to what "doesn't support" means here.

It was my bad. I used older version of sqlite. I moved from "3.50.4-build1" to "3.51.1-build2" and functions are there. Thanks for clarifying.

[vdshb]

About initial idea to make npm repo with full API set enabled (like @sqlite.org/sqlite-wasm-full). It looks like (I haven't done precise checking) missing only rare API under flags:

SQLITE_ENABLE_SNAPSHOT
SQLITE_ENABLE_NORMALIZE
SQLITE_ENABLE_STMT_SCANSTATUS
SQLITE_ENABLE_UNLOCK_NOTIFY

I don't use them myself and have no plans to using them. But it still might be useful to make a repo with such API enabled. I don't know. I have no idea how hard to support such repo would be and how usable/useless missing API might be in js/wasm environment. Only metadata API under SQLITE_ENABLE_COLUMN_METADATA flag were essential for me.

So, I wouldn't mind this issue is closed until some maintainer thinks that idea worth to implement/keep in mind/discuss.

[sgbeal]

I don't know. I have no idea how hard to support such repo would be and how usable/useless missing API might be in js/wasm environment.

Adding new C bindings in the upstream build requires:

• Extending the list of exported functions for Emscripten's -sEXPORTED_FUNCTIONS=@filename flag.
• Editing sqlite3-wasm.c::sqlite3__wasm_enum_json() if new non-function symbols will be exported, e.g. new result codes or SQLITE_OPEN_... flags or the like.
• Adding JS-side entries of the mappings to sqlite3-api-glue.js so the library knows how to convert the argument and result types.
• Adding, if appropriate, any JS-specific overloaded argument handling, e.g. automatic conversion from JS functions to WASM functions.
• Adding new tests.
• Adding, if required, any new docs.

That typically involves editing 3, sometimes 4 or 5, upstream source files (not the standalone counting docs, which are in a separate repo).

In the case of build-time-configurable options, it also involves learning how to use the project's build system and custom precompiler to filter those pieces in/out.

But it still might be useful to make a repo with such API enabled.

Feel free to do so. Upstream has no plans to extend that build to support every tweakable combination. Creating anything beyond the few variants it provides requires a deep dive into the beastly build process.