token-goat 2.9.26 → 2.9.29

package/dist/{token-goat-chunk-OSUFN2FV.mjs → token-goat-chunk-XB5KKOCG.mjs}

@@ -8,6 +8,7 @@ import {
 init_define_import_meta_env();
 import * as fs from "node:fs";
 import { createRequire } from "node:module";
+import { pathToFileURL } from "node:url";
 var _require = createRequire(import.meta.url);
 function suppressSqliteExperimentalWarning() {
   const original = process.emit;
@@ -162,18 +163,7 @@ var Statement = class {
   get source() {
     return this.#stmt.sourceSQL;
   }
-  /**
-   * better-sqlite3's `reader` flag: does this statement return rows?
-   *
-   * `node:sqlite` has no equivalent, so it is derived from the prepared statement's own column
-   * count -- SQLite gives a row-producing statement its result columns at prepare time and gives a
-   * non-producing one none. That is a derivation, and this is the third defence-in-depth layer in
-   * `sqlite_query.ts`'s read-only guard, so it is not taken on faith: the driver tests run both
-   * libraries side by side over SELECT, a CTE, VALUES, EXPLAIN, an empty-result SELECT, INSERT,
-   * UPDATE, DELETE, CREATE, a reading PRAGMA and an assigning PRAGMA, and require every verdict to
-   * agree. If a future SQLite statement form ever breaks the equivalence, that test fails rather
-   * than the guard quietly weakening.
-   */
+  /** better-sqlite3's `reader` flag: does this statement return rows? `node:sqlite` has no equivalent, so it is derived from the prepared statement's own column count -- SQLite gives a row-producing statement its result columns at prepare time and gives a non-producing one none. That is a derivation, and this is the third defence-in-depth layer in `sqlite_query.ts`'s read-only guard, so it is not taken on faith: the driver tests run both libraries side by side over SELECT, a CTE, VALUES, EXPLAIN, an empty-result SELECT, INSERT, UPDATE, DELETE, CREATE, a reading PRAGMA and an assigning PRAGMA, and require every verdict to agree. If a future SQLite statement form ever breaks the equivalence, that test fails rather than the guard quietly weakening. */
   get reader() {
     return attempt(() => this.#stmt.columns()).length > 0;
   }
@@ -224,7 +214,8 @@ var Database = class {
     if (wantsExisting && dbPath !== ":memory:" && !fs.existsSync(dbPath)) {
       throw new Error("unable to open database file");
     }
-    this.#db = attempt(() => new DatabaseSync(dbPath, {
+    const target = options.immutable === true ? `${pathToFileURL(dbPath).href}?immutable=1` : dbPath;
+    this.#db = attempt(() => new DatabaseSync(target, {
       readOnly: options.readonly === true,
       // sqlite-vec is loaded through db.loadExtension by initConnection, which node:sqlite refuses unless the connection opted in at construction. Harmless when no extension is ever loaded.
       allowExtension: true,
@@ -269,18 +260,7 @@ var Database = class {
   close() {
     attempt(() => this.#db.close());
   }
-  /**
-   * Wrap `fn` so it runs inside a transaction, committing on return and rolling back on throw.
-   *
-   * Nesting uses SAVEPOINT, which is what makes it safe for a transactional helper to call another
-   * one: an inner `BEGIN` would throw ("cannot start a transaction within a transaction"), an inner
-   * SAVEPOINT composes. Whether we are nested is read from SQLite via `isTransaction` rather than
-   * tracked in a counter here, so a transaction some other code path opened still nests correctly.
-   *
-   * The rollback is best-effort and never replaces the caller's error: if the ROLLBACK itself fails
-   * -- the connection died, the transaction was already unwound -- the original failure is still
-   * what propagates, because that is the one that explains what went wrong.
-   */
+  /** Wrap `fn` so it runs inside a transaction, committing on return and rolling back on throw. Nesting uses SAVEPOINT, which is what makes it safe for a transactional helper to call another one: an inner `BEGIN` would throw ("cannot start a transaction within a transaction"), an inner SAVEPOINT composes. Whether we are nested is read from SQLite via `isTransaction` rather than tracked in a counter here, so a transaction some other code path opened still nests correctly. The rollback is best-effort and never replaces the caller's error: if the ROLLBACK itself fails -- the connection died, the transaction was already unwound -- the original failure is still what propagates, because that is the one that explains what went wrong. */
   transaction(fn) {
     const build = (beginSql) => (...args) => {
       if (this.#db.isTransaction) {