Factory functions that turn Zod schemas into a typed, durable workflow API.
A Smithers workflow is built from a single factory call. You hand it Zod schemas;
it owns the storage layer and hands back a typed set of JSX components plus the
smithers() wrapper that produces a runnable SmithersWorkflow.createSmithers is synchronous and SQLite-only. The other factories exist for
the cases it cannot serve: Postgres/PGlite backends, environment-resolved
backends, store migration, and non-JSX (external) build functions.
import { createSmithers, createSmithersPostgres, openSmithersBackend, migrateSmithersStore, createExternalSmithers,} from "smithers-orchestrator";
smithers, Workflow, Task, useCtx, outputs, tables, and db are
returned by the factory, not imported. The component set is documented in the
Components reference; this page covers the factories
themselves.
Schema-driven workflow API over a local SQLite database. The schemas you pass
become both the output tables and the typed outputs accessor. This is the
default entry point for almost every workflow.
function createSmithers<Schemas extends Record<string, ZodObject>>( schemas: Schemas, opts?: CreateSmithersOptions,): CreateSmithersApi<Schemas>;
A map of output name to Zod object schema. Each key becomes a property on
outputs and a backing table. Use the reserved input key to type the
workflow’s run input.
The backend the API was resolved to. createSmithers serves only
"sqlite"; "pglite"/"postgres" fail loud here and require
openSmithersBackend or createSmithersPostgres.
PostgreSQL or PGlite equivalent of createSmithers. Asynchronous because it
opens a connection, and it returns an extra close(). Reach for it when a run
must outlive a single process or be shared across hosts.
Resolve the backend from the environment instead of hard-coding it. Reads
smithers.config / env vars and returns whichever of SQLite, PGlite, or Postgres
they select. Use it in shared CLIs and servers that should honor a deployment’s
configured store.
Copy an existing SQLite store into PGlite or Postgres, table by table, and write
a migration marker. Use it once when graduating a project from the local SQLite
default to a shared backend.
function migrateSmithersStore( opts?: MigrateSmithersStoreOptions,): Promise<SmithersMigrationResult>;
Build a SmithersWorkflow from a plain build function instead of JSX. The build
function returns a HostNodeJson tree that maps 1:1 to what the JSX renderer
produces, so a workflow can be authored in any language that can emit that JSON.