shopify app dev refused to push the 3 mandatory compliance-topic webhooks
(customers/data_request, customers/redact, shop/redact) with "This app is
not approved to subscribe to webhook topics containing protected customer
data" — subscribing to these requires the org to first request and be
granted Protected Customer Data Access in the Partner Dashboard, a manual
approval step outside the CLI/config entirely.
Commented out the three subscription blocks in shopify.app.toml (handlers
are untouched and still fully wired) so dev can proceed now. README.md
gets a new "Before public launch" section as the reminder to re-enable
them once access is granted — this is a hard requirement for BfS/public
submission per CLAUDE.md, not something to forget once dev is unblocked.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
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>
Bootstraps from Shopify's official shopify-app-template-remix (cloned
directly rather than via `shopify app init`, which requires an interactive
Partner login unavailable in this session):
- Prisma (SQLite dev / Postgres-ready) with baseline Session model + migration
- Vitest configured for unit tests, Playwright configured for E2E
- Redis client + BullMQ worker skeleton (app/lib/redis.server.ts, jobs/worker.ts)
- shopify.app.toml: minimal scopes, GDPR + orders webhooks wired (stub handlers),
app proxy config for the future storefront widget
- Stripped template-repo-only meta files (CLA, issue templates, demo product
page) and replaced CI with a lint+typecheck+test workflow
- Bumped @shopify/shopify-app-session-storage-prisma to resolve a duplicate
@shopify/shopify-api install that broke typecheck
- Dropped the Jest-only ESLint config (template default) since the project
standardizes on Vitest per IMPLEMENTATION_PLAN.md
Verified: npm install, lint, typecheck, unit tests, prisma migrate dev, and
npm run build all pass on Node 22 LTS.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
metatroncubeswdev