@pikku/deploy-standalone 0.12.13 → 0.12.19

package/CHANGELOG.md

@@ -1,5 +1,186 @@
 # @pikku/deploy-standalone
 
+## 0.12.19
+
+### Patch Changes
+
+- 7434e65: Stop mangling identifiers in a bundle that a second bundler will mangle again.
+
+  Every standalone bun binary died at boot on `TypeError: t6 is not a function`. The bundle
+  esbuild wrote was correct; `bun build --compile`, which is the documented next step for
+  that runtime, renamed the parameter of the already-mangled `wireCLI` to `t6` — the name
+  esbuild had given the top-level `registerCLICommands` that same function calls — and the
+  inner reference then resolved to the parameter object.
+
+  Neither pass is wrong on its own, so the fix is to stop running both: a provider now
+  declares `getMangleIdentifiers()`, and the standalone adapter returns false for the bun
+  runtime, where `bundle.js` is an input rather than the artifact that runs. Whitespace and
+  syntax minification are unaffected, and every other provider still ships a fully mangled
+  bundle — `minify: true` could not express that, because esbuild ORs it over the granular
+  flags and silently ignores a `minifyIdentifiers: false` set beside it.
+
+- Updated dependencies [7434e65]
+  - @pikku/deploy@0.12.7
+
+## 0.12.18
+
+### Patch Changes
+
+- 265df92: Lift `PlatformServiceContributor` into `@pikku/deploy` so any provider adapter
+  can accept the same service contributors.
+
+  A contributor now declares the binding sources its emitted code reads from
+  (`requires`, defaulting to `env`). An adapter that cannot provide one of them
+  refuses the contributor by name at construction instead of silently emitting
+  code that reads bindings the runtime never has.
+
+  `@pikku/deploy-cloudflare` keeps its entry output unchanged and re-exports the
+  type from the core package. The container entry it generates now runs only the
+  contributors that live on `env`. `@pikku/deploy-standalone` gains a
+  `contributors` option: both the node and bun entries build the contributed
+  services from `process.env` and spread them last into
+  `createSingletonServices`, so a contributed service overrides the in-process
+  default.
+
+- Updated dependencies [265df92]
+  - @pikku/deploy@0.12.6
+
+## 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

package/dist/adapter.d.ts

@@ -16,7 +16,8 @@
  *   compiles the bundle into a single self-contained executable via
  *   `bun build --compile`. No runtime needed on the target host.
  */
-import type { EntryGenerationContext, ProviderAdapter } from '@pikku/deploy';
+import type { BindingSource, EntryGenerationContext, PlatformServiceContributor, ProviderAdapter } from '@pikku/deploy';
+export declare const STANDALONE_BINDING_SOURCES: readonly BindingSource[];
 export type StandaloneRuntime = 'node' | 'bun';
 /**
  * Directory the built frontend is copied to, both inside the unit and beside
@@ -48,6 +49,7 @@ export interface StandaloneProviderAdapterOptions {
      * The window is a webview onto that origin and nothing else is shipped.
      */
     desktopUrl?: string;
+    contributors?: PlatformServiceContributor[];
 }
 export declare class StandaloneProviderAdapter implements ProviderAdapter {
     readonly name = "standalone";
@@ -58,7 +60,12 @@ export declare class StandaloneProviderAdapter implements ProviderAdapter {
     readonly projectDir?: string;
     readonly desktopIdentifier?: string;
     readonly desktopUrl?: string;
+    readonly contributors: PlatformServiceContributor[];
     constructor(options?: StandaloneProviderAdapterOptions);
+    private contributorImportLines;
+    private platformServicesBlock;
+    private platformServicesCallLines;
+    private platformServicesSpreadLines;
     generateEntrySource(ctx: EntryGenerationContext): string;
     private generateNodeEntrySource;
     private generateBunEntrySource;
@@ -66,6 +73,24 @@ 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[];
+    /**
+     * The bun bundle is not the artifact that runs — `bun build --compile` turns
+     * it into the binary — so esbuild must not rename anything bun will rename
+     * again. See `getMangleIdentifiers` on the adapter interface for the boot
+     * failure the two passes produce together.
+     */
+    getMangleIdentifiers(): boolean;
     getPlatform(): 'node';
     deploy(options: {
         buildDir: string;