Local development
Dev server
Section titled “Dev server”bun run devvite dev runs your theme in workerd via @cloudflare/vite-plugin — the same runtime that
serves it in production, with hot reload. What works locally works deployed.
Credentials: .dev.vars
Section titled “Credentials: .dev.vars”Your loaders talk to a real Storefront API. The scaffolder writes the connection into
.dev.vars (gitignored); if you skipped that step, copy the example and fill it in:
cp .dev.vars.example .dev.varsThe variables that matter day to day:
| Variable | Purpose |
|---|---|
STOREFRONT_API_ENDPOINT |
Your shop’s Storefront API URL |
STOREFRONT_API_TOKEN |
A workspace API key for local reads |
KOTAO_SHOP_ID / KOTAO_SITE_ID |
The shop / storefront site your data comes from |
Typed GraphQL
Section titled “Typed GraphQL”Write queries as #graphql documents (see app/graphql/queries.ts), then generate types from
your Storefront API:
bun run codegenThis introspects $STOREFRONT_API_ENDPOINT (or a local SDL file via --schema) and emits
app/graphql/storefrontapi.generated.d.ts.
Runtime constraints (untrusted mode)
Section titled “Runtime constraints (untrusted mode)”Themes run as untrusted Workers in production. Keep these in mind — they are the things that work in a naive local setup but fail deployed:
- No
request.cf— geo data arrives as the typedcontext.geoinstead. - No
eval/new Function. - No shared cache or advancing wall clock within a request — don’t build logic on either.
kotao storefront dev reproduces these constraints locally when you want to verify against them.