@pikku/deploy 0.12.10 → 0.12.12

package/CHANGELOG.md

@@ -1,5 +1,40 @@
 # @pikku/deploy
 
+## 0.12.12
+
+### Patch Changes
+
+- 1fe79bc: SQLite extensions now load under bun on macOS. Bun there opens Apple's SQLite, which is built without extension loading, so the CLI points bun at Homebrew's libsqlite3 (`brew install sqlite`) as it starts, or at the one `PIKKU_SQLITE_LIBRARY` names; without one it warns and carries on without extensions. A bun standalone build on macOS embeds that libsqlite3 and opens its database with it, and fails if the build machine has none. Linux is unchanged: bun there brings a SQLite that loads extensions, and node uses `node:sqlite` everywhere.
+- 1fe79bc: A standalone build of a SQLite app now ships its `db.sqliteExtensions` (sqlite-vec's vec0 by default) inside the artifact, so a migration or query that uses them works in production the way it does under `pikku dev`. The node bundle loads them from `sqlite-extensions/` beside itself; a compiled bun binary embeds them and writes them out under `$PIKKU_DATA_DIR/.pikku-sqlite-extensions/` on start. The libraries are the build machine's, so an extension that cannot be resolved there fails the build; `[]` builds without them.
+
+  `createNodeSqliteKysely` and `createBunSqliteKysely` take an `extensions` list of library paths to load into the connection.
+
+## 0.12.11
+
+### Patch Changes
+
+- d10f5c2: Resolve a standalone build's database the way every other pikku host resolves it.
+
+  A standalone artifact opens its own database, and decided it had one by looking
+  for `db/sqlite` or `db/postgres` on disk. Every other host goes through
+  `loadUserConfigForDb`: `createConfig`'s `sqliteDb` / `postgresUrl` first, the
+  directory conventions only as the fallback. An app that declares its database in
+  config and keeps no migrations therefore got a `kysely` under `pikku dev` and
+  none in its artifact — a clean build, a plausible 94MB bundle, and a first run
+  that died on the line of `createSingletonServices` that reads it.
+
+  The build now asks the same question in the same order. Only the engine travels:
+  a configured SQLite path is a developer's local file and has no meaning on the
+  target host, which still names its own through `PIKKU_DATA_DIR`. Declaring both
+  dialects is refused by name, matching the existing refusal of two migration
+  directories, and a `createConfig` that cannot be loaded falls back to the
+  directories rather than failing a build — a project with no database at all must
+  still bundle.
+
+  Two JSDoc blocks that had drifted off their declarations are reattached:
+  `EntryGenerationContext['db']`, which was documenting `version`, and
+  `resolveStandaloneDb`, which was documenting `resolveProjectVersion`.
+
 ## 0.12.10
 
 ### Patch Changes

package/dist/provider-adapter.d.ts

@@ -51,6 +51,15 @@ export interface EntryGenerationContext {
         urlPrefix: string;
         spaFallback: boolean;
     };
+    /**
+     * The project's own version, for the artifact to report as its own.
+     *
+     * An operator holding a bundle on a machine has no other way to tell which
+     * build it is — there is no manifest to read and no registry to ask — and
+     * "which version is actually running" is the first question of every
+     * incident.
+     */
+    version?: string;
     /**
      * The database the generated entry has to open for itself, or undefined when
      * the project has none.
@@ -66,15 +75,6 @@ export interface EntryGenerationContext {
      * business — a compiled bun binary and a node bundle do not open SQLite the
      * same way, and Postgres is reached by URL rather than by path at all.
      */
-    /**
-     * The project's own version, for the artifact to report as its own.
-     *
-     * An operator holding a bundle on a machine has no other way to tell which
-     * build it is — there is no manifest to read and no registry to ask — and
-     * "which version is actually running" is the first question of every
-     * incident.
-     */
-    version?: string;
     db?: {
         engine: 'sqlite' | 'postgres';
         /**
@@ -86,6 +86,23 @@ export interface EntryGenerationContext {
          * the same reason.
          */
         coercionImportPath?: string;
+        /**
+         * File names of the loadable SQLite extensions the build staged into
+         * `<unitDir>/sqlite-extensions/`, from `db.sqliteExtensions` (sqlite-vec's
+         * `vec0` by default). SQLite only; absent when there are none.
+         *
+         * Beside the directory is `sqlite-extensions.gen.js`, which embeds each
+         * one with `with { type: 'file' }` for a runtime that compiles to a single
+         * binary.
+         */
+        sqliteExtensions?: string[];
+        /**
+         * File name of the libsqlite3 the build staged beside the extensions, for a
+         * runtime that must be pointed at one before it opens a database — bun on
+         * macOS, whose own is Apple's and cannot load extensions. Also embedded by
+         * `sqlite-extensions.gen.js`. Absent everywhere else.
+         */
+        sqliteLibrary?: string;
     };
     /**
      * The app's `pikkuServerLifecycle` export, when it declares one.
@@ -129,6 +146,13 @@ export interface ProviderAdapter {
      *   `wireQueue(...)` user code are unaffected.
      */
     readonly workflowQueues?: boolean;
+    /**
+     * Whether the artifact opens SQLite through a libsqlite3 it has to carry
+     * itself. True for a compiled bun binary: on macOS bun otherwise opens
+     * Apple's SQLite, which cannot load extensions, so the build ships the host's
+     * own libsqlite3 and the entry points bun at it before the first open.
+     */
+    readonly bundlesSqliteLibrary?: boolean;
     /**
      * Generate the entry file source for a deployment unit.
      * Called once per unit.

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@pikku/deploy",
-  "version": "0.12.10",
+  "version": "0.12.12",
   "repository": {
     "type": "git",
     "url": "git+https://github.com/pikkujs/pikku.git",