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>
65 lines
3.2 KiB
Markdown
65 lines
3.2 KiB
Markdown
# 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](./PRODUCT_STRATEGY.md)** (why) and
|
|
**[IMPLEMENTATION_PLAN.md](./IMPLEMENTATION_PLAN.md)** (how, phased build
|
|
order) before making changes. [CLAUDE.md](./CLAUDE.md) holds the
|
|
non-negotiables for AI-assisted work in this repo.
|
|
|
|
## Getting started
|
|
|
|
```sh
|
|
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`.
|