Skip to main content
A Smithers workflow is built from a single factory call. 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 cover what it can’t: Postgres/PGlite backends, environment-resolved backends, store migration, and non-JSX (external) build functions.
The factory returns smithers, useCtx, outputs, tables, db, and workflow-context-bound component primitives like Workflow and Task; those primitives are also exported from smthrs directly. The Components reference covers that component set; this page covers the factories themselves.

createSmithers

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.
Record<string, ZodObject>
required
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.
CreateSmithersOptions
Optional metadata and storage configuration.
object
The typed authoring surface.
Source create.js · CreateSmithersApi.ts · Tests create-unit.test.js · See also Get started, JSX overview

createSmithersPostgres

PostgreSQL or PGlite equivalent of createSmithers. Asynchronous because it opens a connection, and returns an extra close(). Reach for it when a run must outlive a single process or be shared across hosts.
Record<string, ZodObject>
required
Same as createSmithers.
CreateSmithersPostgresOptions
Extends CreateSmithersOptions with the backend connection: a discriminated union on provider.
object
The same API as createSmithers, plus close() to release the connection pool when the process is done with the backend.
Source create.js · See also Control-plane deployment, migrateSmithersStore

openSmithersBackend

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.
Record<string, ZodObject>
Optional output schemas; omit to open the backend without registering tables.
OpenSmithersBackendOptions
Extends CreateSmithersOptions.
object
The authoring API for the resolved backend; close() is present when the backend holds a connection (PGlite/Postgres).
Source openSmithersBackend.js · Tests openSmithersBackend.test.js · See also Package configuration

migrateSmithersStore

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.
MigrateSmithersStoreOptions
object
Source migrateSmithersStore.js · Tests migrateSmithersStore.test.js

createExternalSmithers

Build a SmithersWorkflow from a plain build function instead of JSX. The build function returns a HostNodeJson tree mapping 1:1 to what the JSX renderer produces, so a workflow can be authored in any language that can emit that JSON.
ExternalSmithersConfig<S>
required
object
A runnable workflow plus its backing tables and a cleanup() to release the database.
Source external/index.js · Tests create-unit.test.js · See also SerializedCtx, HostNodeJson
Once you have a SmithersWorkflow, run it with the Runtime API or the CLI; for the full type surface, see the Types reference.