API reference › @evolu/sqlite-wasm › installWasmFunctions

function installWasmFunctions(
  deps: ReportDefectDep & SqliteWasmDep,
): (
  functions: readonly [SqliteWasmFunction, SqliteWasmFunction],
) => SqliteWasmFunctions;

Defined in: packages/sqlite-wasm/src/Wasm.ts:922

Installs functions into the function table.

No engine exposes WebAssembly.Function, so a JavaScript function becomes a wasm function by being imported into a generated module that re-exports it. All functions of one call share one generated module. A call through one costs a few nanoseconds more than a call to a plain import, for the wrapper that catches exceptions: 12 ns against 9 ns in Node.js 24. A signature the notation does not cover throws. Compiling the generated module needs 'wasm-unsafe-eval' under a Content Security Policy; without it, this throws a WebAssembly.CompileError.

No exception crosses into wasm. What a function throws is reported with ReportDefect, and the call returns SQLITE_ERROR, or nothing for a v result. So a commit hook rolls back, an sqlite3_exec callback aborts, and a VFS method fails, but a busy handler retries, forever if it always throws, and a SQL function's xFunc returns NULL. A function whose failure must mean something else catches its own errors, such as an xFunc calling sqlite3_result_error. An i function that returns something other than a number, or undefined for 0, is also reported as a defect and returns SQLITE_ERROR. Two kinds pass through, because they unwound C frames without cleanup: a WebAssembly.RuntimeError, which comes from a trap or a C stack overflow in wasm the function called, and anything thrown once the instance is broken, such as a JavaScript stack overflow that escaped a nested SqliteWasm.call. A function that returns once the instance is broken, as one that caught what a nested call rethrew, or whose ReportDefect broke it, throws the refusal of a broken instance instead, so SQLite never resumes on that state.

Disposing the result empties its slots and keeps them for later installs, so per-database callbacks, such as an update hook, do not grow the table with each open. Dispose only once SQLite can no longer call the functions, for example after closing the database that holds them or replacing a hook: a call through an emptied slot traps, and a reused slot calls another function. A VFS's methods stay installed for the lifetime of the instance.