@sqlite.org/sqlite-wasm - npm Package Compare versions

Comparing version 3.43.1-build1 to 3.43.2-build1

bin/index.js

@@ -42,10 +42,2 @@ import fs from 'fs';
     fs.copyFileSync(
-      './node_modules/comlink/dist/esm/comlink.mjs',
-      './src/comlink.mjs',
-    );
-    fs.copyFileSync(
-      './node_modules/comlink/dist/esm/comlink.mjs.map',
-      './src/comlink.mjs.map',
-    );
-    fs.copyFileSync(
       './node_modules/module-workers-polyfill/module-workers-polyfill.min.js',
@@ -52,0 +44,0 @@ './demo/module-workers-polyfill.min.js',

package.json

 {
   "name": "@sqlite.org/sqlite-wasm",
-  "version": "3.43.1-build1",
+  "version": "3.43.2-build1",
   "description": "SQLite Wasm conveniently wrapped as an ES Module.",
@@ -19,8 +19,10 @@ "keywords": [
   "files": [
+    "index.d.ts",
     "index.mjs",
-    "sqlite-wasm/",
-    "src/"
+    "sqlite-wasm/"
   ],
+  "types": "index.d.ts",
   "exports": {
     ".": {
+      "types": "./index.d.ts",
       "import": "./index.mjs",
@@ -30,3 +32,2 @@ "main": "./index.mjs",
     },
-    "./src/comlink.mjs": "./src/comlink.mjs",
     "./package.json": "./package.json"
@@ -63,8 +64,6 @@ },
     "prettier": "^3.0.3",
-    "publint": "^0.2.2",
+    "publint": "^0.2.4",
+    "prettier-plugin-jsdoc": "^1.1.1",
     "shx": "^0.3.4"
-  },
-  "optionalDependencies": {
-    "comlink": "^4.4.1"
   }
 }

README.md

@@ -8,7 +8,14 @@ # SQLite Wasm
 > This project wraps the code of
-> [SQLite Wasm](https://sqlite.org/wasm/doc/trunk/index.md) with _no_ changes.
-> Please do _not_ file issues or feature requests regarding the underlying
-> SQLite Wasm code here. Instead, please follow the
+> [SQLite Wasm](https://sqlite.org/wasm/doc/trunk/index.md) with _no_ changes,
+> apart from added TypeScript types. Please do _not_ file issues or feature
+> requests regarding the underlying SQLite Wasm code here. Instead, please
+> follow the
 > [SQLite bug filing instructions](https://www.sqlite.org/src/wiki?name=Bug+Reports).
+> Filing TypeScript type related issues and feature requests is fine.
 
+> **Warning**
+>
+> **Breaking change:** Version `3.43.2-build1` removes `SqliteClient`. It will
+> be published as a separate package.
+
 ## Installation
@@ -107,30 +114,2 @@
 
-## Usage with the bundled `SQLiteClient` (with OPFS if available):
-
-> **Warning**
->
-> For this to work, you need to set the following headers on your server:
->
-> `Cross-Origin-Opener-Policy: same-origin`
->
-> `Cross-Origin-Embedder-Policy: require-corp`
-
-Import the `@sqlite.org/sqlite-wasm` library in your code and use it as such:
-
-```js
-import { SqliteClient } from '@sqlite.org/sqlite-wasm';
-
-// Must correspond to the path in your final deployed build.
-const sqliteWorkerPath = 'assets/js/sqlite-worker.js';
-// This is the name of your database. It corresponds to the path in the OPFS.
-const filename = '/test.sqlite3';
-
-const sqlite = new SqliteClient(filename, sqliteWorkerPath);
-await sqlite.init();
-
-await sqlite.executeSql('CREATE TABLE IF NOT EXISTS test(a,b)');
-await sqlite.executeSql('INSERT INTO test VALUES(?, ?)', [6, 7]);
-const results = await sqlite.executeSql('SELECT * FROM test');
-```
-
 ## Usage with vite
@@ -169,2 +148,8 @@
 
+## Projects using this package
+
+See the list of
+[npm dependents](https://www.npmjs.com/browse/depended/@sqlite.org/sqlite-wasm)
+for this package.
+
 ## Deploying a new version
@@ -171,0 +156,0 @@

sqlite-wasm/jswasm/sqlite3-opfs-async-proxy.js

@@ -68,15 +68,15 @@ /*
   /**
-     Will hold state copied to this object from the syncronous side of
-     this API.
-  */
+   * Will hold state copied to this object from the syncronous side of
+   *      this API.
+   */
   const state = Object.create(null);
 
   /**
-     verbose:
-
-     0 = no logging output
-     1 = only errors
-     2 = warnings and errors
-     3 = debug, warnings, and errors
-  */
+   * verbose:
+   *
+   *      0 = no logging output
+   *      1 = only errors
+   *      2 = warnings and errors
+   *      3 = debug, warnings, and errors
+   */
   state.verbose = 1;
@@ -139,30 +139,30 @@
   /**
-     __openFiles is a map of sqlite3_file pointers (integers) to
-     metadata related to a given OPFS file handles. The pointers are, in
-     this side of the interface, opaque file handle IDs provided by the
-     synchronous part of this constellation. Each value is an object
-     with a structure demonstrated in the xOpen() impl.
-  */
+   * __openFiles is a map of sqlite3_file pointers (integers) to
+   *      metadata related to a given OPFS file handles. The pointers are, in
+   *      this side of the interface, opaque file handle IDs provided by the
+   *      synchronous part of this constellation. Each value is an object
+   *      with a structure demonstrated in the xOpen() impl.
+   */
   const __openFiles = Object.create(null);
   /**
-     __implicitLocks is a Set of sqlite3_file pointers (integers) which were
-     "auto-locked".  i.e. those for which we obtained a sync access
-     handle without an explicit xLock() call. Such locks will be
-     released during db connection idle time, whereas a sync access
-     handle obtained via xLock(), or subsequently xLock()'d after
-     auto-acquisition, will not be released until xUnlock() is called.
-
-     Maintenance reminder: if we relinquish auto-locks at the end of the
-     operation which acquires them, we pay a massive performance
-     penalty: speedtest1 benchmarks take up to 4x as long. By delaying
-     the lock release until idle time, the hit is negligible.
-  */
+   * __implicitLocks is a Set of sqlite3_file pointers (integers) which were
+   *      "auto-locked".  i.e. those for which we obtained a sync access
+   *      handle without an explicit xLock() call. Such locks will be
+   *      released during db connection idle time, whereas a sync access
+   *      handle obtained via xLock(), or subsequently xLock()'d after
+   *      auto-acquisition, will not be released until xUnlock() is called.
+   *
+   *      Maintenance reminder: if we relinquish auto-locks at the end of the
+   *      operation which acquires them, we pay a massive performance
+   *      penalty: speedtest1 benchmarks take up to 4x as long. By delaying
+   *      the lock release until idle time, the hit is negligible.
+   */
   const __implicitLocks = new Set();
 
   /**
-     Expects an OPFS file path. It gets resolved, such that ".."
-     components are properly expanded, and returned. If the 2nd arg is
-     true, the result is returned as an array of path elements, else an
-     absolute path string is returned.
-  */
+   * Expects an OPFS file path. It gets resolved, such that ".."
+   *      components are properly expanded, and returned. If the 2nd arg is
+   *      true, the result is returned as an array of path elements, else an
+   *      absolute path string is returned.
+   */
   const getResolvedPath = function (filename, splitIt) {
@@ -174,7 +174,7 @@ const p = new URL(filename, 'file://irrelevant').pathname;
   /**
-     Takes the absolute path to a filesystem element. Returns an array
-     of [handleOfContainingDir, filename]. If the 2nd argument is truthy
-     then each directory element leading to the file is created along
-     the way. Throws if any creation or resolution fails.
-  */
+   * Takes the absolute path to a filesystem element. Returns an array
+   *      of [handleOfContainingDir, filename]. If the 2nd argument is truthy
+   *      then each directory element leading to the file is created along
+   *      the way. Throws if any creation or resolution fails.
+   */
   const getDirForFilename = async function f(absFilename, createDirs = false) {
@@ -193,11 +193,11 @@ const path = getResolvedPath(absFilename, true);
   /**
-     If the given file-holding object has a sync handle attached to it,
-     that handle is remove and asynchronously closed. Though it may
-     sound sensible to continue work as soon as the close() returns
-     (noting that it's asynchronous), doing so can cause operations
-     performed soon afterwards, e.g. a call to getSyncHandle() to fail
-     because they may happen out of order from the close(). OPFS does
-     not guaranty that the actual order of operations is retained in
-     such cases. i.e.  always "await" on the result of this function.
-  */
+   * If the given file-holding object has a sync handle attached to it,
+   *      that handle is remove and asynchronously closed. Though it may
+   *      sound sensible to continue work as soon as the close() returns
+   *      (noting that it's asynchronous), doing so can cause operations
+   *      performed soon afterwards, e.g. a call to getSyncHandle() to fail
+   *      because they may happen out of order from the close(). OPFS does
+   *      not guaranty that the actual order of operations is retained in
+   *      such cases. i.e.  always "await" on the result of this function.
+   */
   const closeSyncHandle = async (fh) => {
@@ -215,12 +215,12 @@ if (fh.syncHandle) {
   /**
-     A proxy for closeSyncHandle() which is guaranteed to not throw.
-
-     This function is part of a lock/unlock step in functions which
-     require a sync access handle but may be called without xLock()
-     having been called first. Such calls need to release that
-     handle to avoid locking the file for all of time. This is an
-     _attempt_ at reducing cross-tab contention but it may prove
-     to be more of a problem than a solution and may need to be
-     removed.
-  */
+   * A proxy for closeSyncHandle() which is guaranteed to not throw.
+   *
+   *      This function is part of a lock/unlock step in functions which
+   *      require a sync access handle but may be called without xLock()
+   *      having been called first. Such calls need to release that
+   *      handle to avoid locking the file for all of time. This is an
+   *      _attempt_ at reducing cross-tab contention but it may prove
+   *      to be more of a problem than a solution and may need to be
+   *      removed.
+   */
   const closeSyncHandleNoThrow = async (fh) => {
@@ -247,9 +247,9 @@ try {
   /**
-     An experiment in improving concurrency by freeing up implicit locks
-     sooner. This is known to impact performance dramatically but it has
-     also shown to improve concurrency considerably.
-
-     If fh.releaseImplicitLocks is truthy and fh is in __implicitLocks,
-     this routine returns closeSyncHandleNoThrow(), else it is a no-op.
-  */
+   * An experiment in improving concurrency by freeing up implicit locks
+   *      sooner. This is known to impact performance dramatically but it has
+   *      also shown to improve concurrency considerably.
+   *
+   *      If fh.releaseImplicitLocks is truthy and fh is in __implicitLocks,
+   *      this routine returns closeSyncHandleNoThrow(), else it is a no-op.
+   */
   const releaseImplicitLock = async (fh) => {
@@ -262,19 +262,19 @@ if (fh.releaseImplicitLocks && __implicitLocks.has(fh.fid)) {
   /**
-     An error class specifically for use with getSyncHandle(), the goal
-     of which is to eventually be able to distinguish unambiguously
-     between locking-related failures and other types, noting that we
-     cannot currently do so because createSyncAccessHandle() does not
-     define its exceptions in the required level of detail.
-
-     2022-11-29: according to:
-
-     https://github.com/whatwg/fs/pull/21
-
-     NoModificationAllowedError will be the standard exception thrown
-     when acquisition of a sync access handle fails due to a locking
-     error. As of this writing, that error type is not visible in the
-     dev console in Chrome v109, nor is it documented in MDN, but an
-     error with that "name" property is being thrown from the OPFS
-     layer.
-  */
+   * An error class specifically for use with getSyncHandle(), the goal
+   *      of which is to eventually be able to distinguish unambiguously
+   *      between locking-related failures and other types, noting that we
+   *      cannot currently do so because createSyncAccessHandle() does not
+   *      define its exceptions in the required level of detail.
+   *
+   *      2022-11-29: according to:
+   *
+   *      https://github.com/whatwg/fs/pull/21
+   *
+   *      NoModificationAllowedError will be the standard exception thrown
+   *      when acquisition of a sync access handle fails due to a locking
+   *      error. As of this writing, that error type is not visible in the
+   *      dev console in Chrome v109, nor is it documented in MDN, but an
+   *      error with that "name" property is being thrown from the OPFS
+   *      layer.
+   */
   class GetSyncHandleError extends Error {
@@ -307,13 +307,13 @@ constructor(errorObject, ...msg) {
   /**
-     Returns the sync access handle associated with the given file
-     handle object (which must be a valid handle object, as created by
-     xOpen()), lazily opening it if needed.
-
-     In order to help alleviate cross-tab contention for a dabase, if
-     an exception is thrown while acquiring the handle, this routine
-     will wait briefly and try again, up to some fixed number of
-     times. If acquisition still fails at that point it will give up
-     and propagate the exception. Client-level code will see that as
-     an I/O error.
-  */
+   * Returns the sync access handle associated with the given file
+   *      handle object (which must be a valid handle object, as created by
+   *      xOpen()), lazily opening it if needed.
+   *
+   *      In order to help alleviate cross-tab contention for a dabase, if
+   *      an exception is thrown while acquiring the handle, this routine
+   *      will wait briefly and try again, up to some fixed number of
+   *      times. If acquisition still fails at that point it will give up
+   *      and propagate the exception. Client-level code will see that as
+   *      an I/O error.
+   */
   const getSyncHandle = async (fh, opName) => {
@@ -378,5 +378,5 @@ if (!fh.syncHandle) {
   /**
-     Stores the given value at state.sabOPView[state.opIds.rc] and then
-     Atomics.notify()'s it.
-  */
+   * Stores the given value at state.sabOPView[state.opIds.rc] and then
+   *      Atomics.notify()'s it.
+   */
   const storeAndNotify = (opName, value) => {
@@ -388,5 +388,3 @@ log(opName + '() => notify(', value, ')');
 
-  /**
-     Throws if fh is a file-holding object which is flagged as read-only.
-  */
+  /** Throws if fh is a file-holding object which is flagged as read-only. */
   const affirmNotRO = function (opName, fh) {
@@ -397,8 +395,8 @@ if (fh.readOnly) toss(opName + '(): File is read-only: ' + fh.filenameAbs);
   /**
-     We track 2 different timers: the "metrics" timer records how much
-     time we spend performing work. The "wait" timer records how much
-     time we spend waiting on the underlying OPFS timer. See the calls
-     to mTimeStart(), mTimeEnd(), wTimeStart(), and wTimeEnd()
-     throughout this file to see how they're used.
-  */
+   * We track 2 different timers: the "metrics" timer records how much
+   *      time we spend performing work. The "wait" timer records how much
+   *      time we spend waiting on the underlying OPFS timer. See the calls
+   *      to mTimeStart(), mTimeEnd(), wTimeStart(), and wTimeEnd()
+   *      throughout this file to see how they're used.
+   */
   const __mTimer = Object.create(null);
@@ -427,14 +425,14 @@ __mTimer.op = undefined;
   /**
-     Gets set to true by the 'opfs-async-shutdown' command to quit the
-     wait loop. This is only intended for debugging purposes: we cannot
-     inspect this file's state while the tight waitLoop() is running and
-     need a way to stop that loop for introspection purposes.
-  */
+   * Gets set to true by the 'opfs-async-shutdown' command to quit the
+   *      wait loop. This is only intended for debugging purposes: we cannot
+   *      inspect this file's state while the tight waitLoop() is running and
+   *      need a way to stop that loop for introspection purposes.
+   */
   let flagAsyncShutdown = false;
 
   /**
-     Asynchronous wrappers for sqlite3_vfs and sqlite3_io_methods
-     methods, as well as helpers like mkdir(). Maintenance reminder:
-     members are in alphabetical order to simplify finding them.
-  */
+   * Asynchronous wrappers for sqlite3_vfs and sqlite3_io_methods
+   *      methods, as well as helpers like mkdir(). Maintenance reminder:
+   *      members are in alphabetical order to simplify finding them.
+   */
   const vfsAsyncImpls = {
@@ -777,5 +775,5 @@ 'opfs-async-metrics': async () => {
     /**
-       ACHTUNG: this code is 100% duplicated in the other half of this
-       proxy! The documentation is maintained in the "synchronous half".
-    */
+     * ACHTUNG: this code is 100% duplicated in the other half of this
+     *        proxy! The documentation is maintained in the "synchronous half".
+     */
     if (state.s11n) return state.s11n;
@@ -782,0 +780,0 @@ const textDecoder = new TextDecoder(),

New alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Fixed alerts

License Policy Violation

License

This package is not allowed per your license policy. Review the package's license to ensure compliance.

Found 1 instance in 1 package

Improved metrics

Total package byte prevSize

3081521

increased by9.06%

Dependency count

0

decreased by-100%

Lines of code

59833

increased by13.44%

Worsened metrics

Dev dependency count

9

increased by12.5%

Number of package files

15

decreased by-16.67%

Number of lines in readme file

174

decreased by-7.94%

No dependency changes