381c52d01a
The user linked the app to a real Partner org and hit two live errors
running `shopify app dev`, which is exactly the verification the earlier
hand-scaffolded Functions couldn't get in this environment. Root-caused and
fixed both, then went further: regenerated both Functions from scratch via
`shopify app generate extension` (now possible — the user's session had
authenticated) instead of patching the guesses.
What broke and why:
- `shopify app config link` pulled a fresh app's (empty) remote config and
overwrote shopify.app.toml, dropping the webhook subscriptions and
app_proxy block — restored both, keeping the real client_id/name/scopes
the CLI set.
- `[extensions.build.watch]` as a nested table was invalid TOML for this
field — it's a plain `watch = [...]` array directly under
`[extensions.build]`.
- The real failure ("doesn't have a build command or it's empty") turned
out to be a red herring pointing at a stale filename
(shopify.function.extension.toml, not the current shopify.extension.toml)
— the actual problem was that `@shopify/shopify_function` was never
installed for these extensions (confirmed: no node_modules), because
hand-writing package.json doesn't run the install step
`shopify app generate extension` does automatically.
Rather than keep guessing at the toolchain, regenerated both Functions for
real:
- `shopify app generate extension --template=cart_checkout_validation` and
`--template=delivery_customization` (--flavor=vanilla-js), which produces
a working vite/vitest-based build+test setup, real
`@shopify/shopify-function-test-helpers` fixture testing (builds actual
WASM and runs it via function-runner), and a generated GraphQL type file
per extension.
- This surfaced several concrete corrections to what was hand-written
before: the real target names are `cart.validations.generate.run` and
`cart.delivery-options.transform.run` (not `purchase.validation.run` /
`purchase.delivery-customization.run`), current api_version is 2026-07
(not 2025-01), the validation output wraps errors in
`operations: [{ validationAdd: { errors } }]` with a plain `message`
field (not top-level `errors` with `localizedMessage`), and the rename
operation is `deliveryOptionRename: { deliveryOptionHandle, title }` (not
`rename: { deliveryOptionHandle, title }`).
- Rewrote each extension's `.graphql` input query to request our actual
dd_* cart attributes (plus delivery option handles for the rename case),
regenerated types via `npm run typegen` in each, and ported the pure
evaluate.js decision logic (same exported function names/behavior as
before, now proven correct against the live schema) into the adapter
file the generator expects.
- Replaced each extension's demo fixture with ones matching our real
logic; `npm test` inside each extension now compiles real WASM and runs
function-runner against them — this is strictly stronger verification
than the previous pure-JS-only unit tests (which are kept too, unchanged,
since the evaluate.js files kept the same interface).
Repo-wide wiring: extensions/*/generated and extensions/*/dist are not
committed (matches the CLI's own per-extension .gitignore) — added
`npm run typegen:functions` (runs automatically before `npm run typecheck`
via a pretypecheck hook) and `npm run test:functions`, both now also in CI.
Root `npm install` picked these two folders up as proper npm workspace
members (they already have their own package.json from generation).
Verified: lint, typecheck, all 52 unit tests, all 8 integration tests, both
extensions' real WASM/function-runner test suites (5 fixtures total), and
both `npm run build` / `npm run build:widget` all pass.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Delivery Date & Time
Shopify app: scheduling for Shipping / Local Delivery / Store Pickup, with date-time slots, capacity intelligence, and all-plan checkout enforcement via Cart/Checkout Validation Functions.
Read PRODUCT_STRATEGY.md (why) and IMPLEMENTATION_PLAN.md (how, phased build order) before making changes. CLAUDE.md holds the non-negotiables for AI-assisted work in this repo.
Getting started
npm install
cp .env.example .env # fill in Shopify app credentials after linking
docker compose up -d # local Postgres (5433) + Redis (6380)
npx prisma migrate dev
npm run dev # shopify app dev — requires `shopify auth login` first
Dev uses Postgres, same as prod, since the schema relies on Prisma enums and
(from Phase 5 on) array fields that SQLite can't express. npm run worker
runs the BullMQ worker (jobs/worker.ts) once Phase 4 makes it do anything.
Commands
| Command | Purpose |
|---|---|
npm run dev |
shopify app dev — local dev against a dev store |
npm test |
Vitest unit tests |
npm run test:e2e |
Playwright E2E |
npm run lint / npm run typecheck |
ESLint / tsc --noEmit |
npx prisma migrate dev |
DB migrations |
npm run deploy |
shopify app deploy — deploy extensions/functions |
npm run worker |
BullMQ worker (hold-expiry, notifications) |
npm run test:integration |
Redis/Postgres-backed tests (slot-hold concurrency, booking flow) — needs docker compose up -d |
npm run test:functions |
Real WASM build + function-runner tests for both Shopify Functions, against fixtures |
npm run typegen:functions |
Regenerate extensions/*/generated/api.ts from each Function's schema.graphql + .graphql query (also runs automatically before npm run typecheck) |
Status
Phase 0 (scaffold & CI) through Phase 4 (enforcement Functions +
slot-holds) are complete. See §6 of IMPLEMENTATION_PLAN.md for the phased
build order and acceptance criteria — next up is Phase 5 (multi-location,
zones, rates, auto-assignment).
Editing the storefront widget's extensions/datetime-widget/src/? Run
npm run build:widget to rebuild assets/datetime-widget.js — it also runs
automatically before npm run dev / npm run deploy.
Functions are JavaScript, not Rust (extensions/validation-slot/,
extensions/delivery-customization/) — no Rust toolchain was available in
the environment that built Phase 4, and IMPLEMENTATION_PLAN.md §1
explicitly allows JS as a fallback. Both were generated with
shopify app generate extension (once a real Partner login was available)
and their business logic (src/evaluate.js in each) is verified two ways:
plain Vitest unit tests at the repo root (npm test) and real
function-runner fixture tests that compile actual WASM
(npm run test:functions, also in CI). extensions/*/generated/ and
extensions/*/dist/ aren't committed (matching the CLI's own
.gitignore for these extensions) — npm run typegen:functions
regenerates the types from the committed schema.graphql, and building
runs automatically as part of npm run dev / test:functions.