Sviluppo locale

Server di sviluppo

bun run dev

vite dev esegue il tema in workerd tramite @cloudflare/vite-plugin: lo stesso ambiente che lo serve in produzione, con ricaricamento automatico. Ciò che funziona in locale funziona anche dopo il deployment.

Credenziali: `.dev.vars`

I tuoi loaders parlano a un vero Storefront API. Il scaffolder scrive la connessione in .dev.vars (gitignored); se hai saltato quel passo, copia l’esempio e compila:

cp .dev.vars.example .dev.vars

Le variabili che contano giorno per giorno:

Variabile	Scopo
`STOREFRONT_API_ENDPOINT`	URL dell’API Storefront del negozio
`STOREFRONT_API_TOKEN`	Chiave API dell’area di lavoro per le letture locali
`KOTAO_SHOP_ID` / `KOTAO_SITE_ID`	Negozio / sito da cui provengono i dati

GraphQL tipizzato

Scrivi le query come documenti #graphql (vedi app/graphql/queries.ts), quindi genera i tipi dalla tua API Storefront:

bun run codegen

Il comando esegue l’introspezione di $STOREFRONT_API_ENDPOINT (oppure legge un file SDL locale tramite --schema) e genera app/graphql/storefrontapi.generated.d.ts.

Vincoli dell’ambiente di esecuzione (modalità non attendibile)

In produzione i temi vengono eseguiti come Worker non attendibili. Tieni presenti questi vincoli: sono aspetti che possono funzionare in una configurazione locale semplificata ma non dopo il deployment:

Nessun request.cf — i dati geografici arrivano invece tramite l’oggetto tipizzato context.geo.
Nessun eval / new Function.
Nessuna cache condivisa e nessun avanzamento dell’orologio reale durante una richiesta — non basare la logica su questi elementi.

kotao storefront dev riproduce questi vincoli in locale per consentirti di verificarli.