@pikku/deploy-standalone 0.12.12 → 0.12.17

package/CHANGELOG.md

@@ -1,5 +1,182 @@
 # @pikku/deploy-standalone
 
+## 0.12.17
+
+### Patch Changes
+
+- b2e038b: Rename `@pikku/sql-migrator` to `@pikku/migrator-sql`, so a future migrator for
+  another store sorts beside it rather than under a second prefix. The package has
+  never been published under either name, so nothing depends on the old one.
+- Updated dependencies [b2e038b]
+  - @pikku/migrator-sql@0.12.3
+
+## 0.12.16
+
+### Patch Changes
+
+- f970f8f: Rename `@pikku/db-migrator` to `@pikku/migrator-sql`.
+
+  It applies `.sql` files and keeps their bookkeeping; it is not a database
+  service, and `db-` read as though it were one. Nothing was ever published under
+  the old name, so there is no alias to keep.
+
+- Updated dependencies [f970f8f]
+  - @pikku/migrator-sql@0.12.2
+
+## 0.12.15
+
+### Patch Changes
+
+- a057bec: Give a standalone bundle a command line.
+
+  An operator holding a standalone artifact on a machine had one thing they could
+  do with it: start it. Applying the migrations it needs meant a checkout of the
+  project and a second copy of the CLI on a production box, and answering "which
+  build is this" meant asking whoever ran the deploy.
+
+  The bundle now takes a command. `serve` remains the default, so an existing
+  `node bundle.js` is unchanged. `version` prints the version the project declared
+  at build time. `db migrate` and `db status` apply and report the migrations that
+  now ship beside the bundle under `db/<engine>/` — the same path Fabric's build
+  container stages them to, so the two producers of an artifact cannot disagree
+  about where the SQL lives. `backup <path>` writes a consistent copy of a SQLite
+  database with `VACUUM INTO`; on postgres it refuses and names `pg_dump`, which
+  is the tool for it.
+
+  Both engines are supported: a postgres build migrates over the connection it
+  already opens. `PostgresMigrationClient` grew an optional `begin`, because a
+  pooled client is free to answer `BEGIN`, the migration and `COMMIT` on three
+  different connections — which leaves a failed migration half applied with
+  nothing to roll back.
+
+  There is deliberately no way to invoke an RPC. A running server already answers
+  them with auth, sessions and middleware applied; an in-process invoke would
+  answer them with none of that.
+
+- Updated dependencies [a057bec]
+- Updated dependencies [a057bec]
+  - @pikku/migrator-sql@0.12.1
+  - @pikku/deploy@0.12.5
+
+## 0.12.14
+
+### Patch Changes
+
+- 3d75643: Run the app's server lifecycle in generated entries, and make an out-of-band
+  account signable-in.
+
+  `pikkuServerLifecycle` was only ever called by `pikku dev` and `pikku serve`, so
+  an app that seeds its first admin account, probes a dependency, or warms a cache
+  in `beforeStart` did all of that in development and silently skipped it
+  everywhere it was actually deployed. The standalone entry and the shared node
+  server entry — the one behind every `target: 'server'` unit — now import the
+  app's lifecycle and call it: `beforeStart` after `init` and before the port
+  opens, so work that must finish before the first request has, `afterStart` once
+  the server is listening, and the stop hooks handed to the signal handler that
+  already owns shutdown rather than a second listener racing it. Each shutdown
+  step is isolated from the ones after it, so a hook that throws is logged without
+  taking the service teardown and the socket close down with it.
+
+  Separately, `createAuthUser` and `setAuthUserPassword` wrote credential accounts
+  with no `issuer`. From better-auth 1.7 a credential account is matched by its
+  issuer as well as its provider, so those accounts were invisible to sign-in,
+  `updatePassword` and `findCredentialAccount` — a user who plainly existed in the
+  table was reported as "user not found". The field is written only when the
+  resolved schema has it, so older better-auth keeps working, and
+  `setAuthUserPassword` repairs an account that predates the fix.
+
+- 3d75643: Give a standalone artifact the database connection every other provider's runtime hands it.
+
+  `createSingletonServices` receives `kysely` from whatever is hosting the app —
+  `pikku dev` builds one, a Cloudflare deploy binds one — so app code is written
+  expecting it, and the generated templates throw outright when it is absent. The
+  standalone provider is its own host and supplied nothing, so a bundle built from
+  a project with a database started, called the services factory, and died on the
+  first line of it. The artifact was only ever startable by projects that had no
+  database at all, which is not the case the provider exists to serve.
+
+  The generated entry now opens the database itself and passes `kysely` in.
+  `EntryGenerationContext` carries a `db` descriptor, and the engine is read from
+  the migrations directory the project actually wrote — `db/sqlite` or
+  `db/postgres`, the same two conventions the migrator emits to. Having both is
+  refused rather than resolved: choosing on directory order would choose which
+  database the deployed app talks to, and an app running happily against the
+  wrong but entirely valid schema is invisible until someone reads the data.
+
+  For SQLite the adapter emits the dialect its runtime can actually use —
+  `@pikku/kysely-node-sqlite` for the node bundle, `@pikku/kysely-bun-sqlite` for a
+  compiled bun binary, which has no `node:sqlite` to reach for. For Postgres it
+  emits `PikkuKysely` from `@pikku/kysely-postgres`, connected from `DATABASE_URL`,
+  the same variable every other pikku host reads, so an artifact dropped onto a
+  machine already running a pikku app needs no new one. An unset `DATABASE_URL`
+  fails by name rather than as a driver error about an undefined connection
+  string.
+
+  The connection pool is closed on shutdown, in `afterStop` — after the app's own
+  stop hook and the draining server have both finished with it, since a pool
+  closed any earlier takes the queries they are still entitled to make down with
+  it. SQLite needs no counterpart: the process exiting releases the file.
+
+  The project's generated coercion map is applied to either engine, so a deployed
+  app and `pikku dev` agree about which columns are dates and which are booleans.
+  It is attached when the project generated one and skipped when it did not — the
+  map is built from `db/annotations.ts` rather than from the dialect, so an app
+  that annotates no columns is one with nothing to coerce rather than one that
+  should be handed no database at all.
+
+  A SQLite file is located by `PIKKU_DATA_DIR` rather than derived from the bundle's
+  own path: a deploy that swaps the release directory would otherwise take the
+  database with it. `PIKKU_DATABASE_FILE` overrides it outright, for when the path
+  has to match one something else already chose — notably `pikku db migrate`,
+  which has to open the same file or the app runs against an unmigrated schema.
+  Neither being set fails with the variable's name rather than as a SQLite error
+  about a path of `undefined`.
+
+- Updated dependencies [3d75643]
+- Updated dependencies [3d75643]
+  - @pikku/deploy@0.12.4
+
+## 0.12.13
+
+### Patch Changes
+
+- 80eb5c0: Generate a desktop shell from `pikku deploy apply --desktop`
+
+  `pikku deploy apply --provider standalone --runtime bun --desktop` now emits a
+  `src-tauri/` crate that ships the compiled binary as a sidecar and opens a
+  window on the server's own HTTP origin, so cookies, CORS and OAuth behave
+  exactly as they do in a browser. Regeneration is idempotent and leaves an
+  edited file alone rather than overwriting it.
+
+  `--desktop-url https://app.example.com` builds the other shape: a shell that
+  points at an already-deployed server. Nothing is bundled — no sidecar, no
+  binary, and so no bun runtime to compile one — and the window is declared in
+  `tauri.conf.json` rather than opened from Rust, because the origin is known up
+  front. The url can also live in `pikku.config.json` as `deploy.desktop.url`,
+  alongside `deploy.desktop.identifier`.
+
+  Supporting changes: `SERVER_READY_MARKER` moved to `@pikku/deploy` (the CLI
+  re-exports it from its old path), both HTTP runtimes expose the port they
+  actually bound so `--port 0` reports a real port, and the generated server
+  entry exits when its parent process goes away.
+
+- 80eb5c0: feat: serve a built frontend from the pikku server's own origin
+
+  A new `frontend` key in `pikku.config.json` names a directory of built
+  frontend output. `pikku serve` mounts it, and `pikku deploy` ships it inside
+  the distributable — into a directory beside the bundle for the node runtime,
+  and embedded in the binary for a `bun build --compile` standalone. `pikku dev`
+  deliberately ignores it and says so, because the frontend's own dev server owns
+  that job.
+
+  Pikku reads the frontend's output and never builds it, so an unbuilt directory
+  fails with a message that says which build to run rather than booting a server
+  that answers every page with a 404.
+
+- Updated dependencies [80eb5c0]
+- Updated dependencies [80eb5c0]
+  - @pikku/deploy@0.12.2
+
 ## 0.12.12
 
 ### Patch Changes

package/dist/adapter.d.ts

@@ -18,14 +18,46 @@
  */
 import type { EntryGenerationContext, ProviderAdapter } from '@pikku/deploy';
 export type StandaloneRuntime = 'node' | 'bun';
+/**
+ * Directory the built frontend is copied to, both inside the unit and beside
+ * the shipped bundle. The node entry resolves it relative to itself at runtime,
+ * so the two have to agree.
+ */
+export declare const STANDALONE_FRONTEND_DIR = "frontend";
+/**
+ * Module the bun entry imports its embedded assets from. It stays out of the
+ * esbuild bundle — esbuild rejects the `with { type: 'file' }` attribute the
+ * manifest is built on — and is resolved by `bun build --compile` instead.
+ */
+export declare const STANDALONE_FRONTEND_MANIFEST = "./frontend-assets.gen.js";
 export interface StandaloneProviderAdapterOptions {
     runtime?: StandaloneRuntime;
+    /**
+     * Generate a desktop shell (Tauri) around the compiled binary. Requires the
+     * `bun` runtime — the shell ships the binary as a sidecar, and only that
+     * runtime produces one. A shell pointed at {@link desktopUrl} ships no binary
+     * and so has no such requirement.
+     */
+    desktop?: boolean;
+    /** Project root. The shell crate is written to `<projectDir>/src-tauri`. */
+    projectDir?: string;
+    /** Bundle identifier for the shell. Derived from the app name when absent. */
+    desktopIdentifier?: string;
+    /**
+     * An already-deployed server for the shell to open, instead of bundling one.
+     * The window is a webview onto that origin and nothing else is shipped.
+     */
+    desktopUrl?: string;
 }
 export declare class StandaloneProviderAdapter implements ProviderAdapter {
     readonly name = "standalone";
     readonly deployDirName = "standalone";
     readonly singleUnit = true;
     readonly runtime: StandaloneRuntime;
+    readonly desktop: boolean;
+    readonly projectDir?: string;
+    readonly desktopIdentifier?: string;
+    readonly desktopUrl?: string;
     constructor(options?: StandaloneProviderAdapterOptions);
     generateEntrySource(ctx: EntryGenerationContext): string;
     private generateNodeEntrySource;
@@ -34,6 +66,17 @@ export declare class StandaloneProviderAdapter implements ProviderAdapter {
     generateInfraManifest(): string | null;
     generateProviderConfigs(): Map<string, string>;
     getExternals(): string[];
+    /**
+     * The SQLite driver this runtime cannot load.
+     *
+     * `loadSqliteRuntime` picks its driver by looking for `globalThis.Bun`, so a
+     * node process never runs the bun branch — but esbuild still follows the
+     * import, and `bun:sqlite` sits at the top of that module as a static import
+     * it cannot resolve. Left in, the bundle fails to build; marked external, it
+     * becomes a top-level import node fails to load. Stubbing removes the branch
+     * that was already dead.
+     */
+    getStubModules(): string[];
     getPlatform(): 'node';
     deploy(options: {
         buildDir: string;
@@ -50,10 +93,12 @@ export declare class StandaloneProviderAdapter implements ProviderAdapter {
         }[];
         workersDeployed?: undefined;
         resourcesCreated?: undefined;
+        targetTriple?: undefined;
     } | {
         success: boolean;
         workersDeployed: string[];
         resourcesCreated: never[];
         errors: never[];
+        targetTriple: string | undefined;
     }>;
 }