3 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
metatroncubeswdev
|
4a1d4e323f |
fix: add missing shopify.web.toml — root cause of dev preview never loading
Some checks failed
CI / Lint, Unit & Integration Tests (push) Has been cancelled
shopify.web.toml never existed at the repo root. Without it, `shopify app dev` runs the theme/UI-extension/Function dev servers fine but never starts the actual Remix app, and has no local dev-server port to build a tunnel URL from for the embedded admin app — so Admin always showed the generic "Find this app in the pages where you work" fallback, regardless of which app record was linked, cache state, or CLI version. Root-caused via `shopify app dev --verbose`, which showed the CLI's own reverse proxy had a route for /extensions but none for /. Also updates shopify.app.toml's client_id to a freshly linked app (the previous one, and two accidental duplicates created while chasing this bug via `dev --reset`/`config link`, were deleted from the Dev Dashboard), resets application_url/redirect_urls to placeholders now that dev's auto-update actually works, restores checkout-datetime's network_access capability (briefly disabled to test an unrelated theory — confirmed not the real cause), and widens the dev-log gitignore pattern. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> |
||
|
metatroncubeswdev
|
3f77c658d3 |
fix: populate empty checkout-datetime locale file
Some checks failed
CI / Lint, Unit & Integration Tests (push) Has been cancelled
extensions/checkout-datetime/locales/en.default.json was an empty {}
(unlike pos-datetime and datetime-widget, which both have real content) —
shopify app dev's checkout preview refuses to start with "Locale data for
`en` is empty." Checkout.jsx/ThankYou.jsx don't call useTranslate yet (all
strings are hardcoded inline), so this just satisfies the non-empty
requirement and mirrors the extension's visible strings for when it is
wired up to i18n.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|
||
|
metatroncubeswdev
|
5b2207a397 |
feat: Phase 7 — POS + Checkout UI extensions
Some checks failed
CI / Lint, Unit & Integration Tests (push) Has been cancelled
Also fixes the [events] gate that was blocking ALL extension generation
(discovered while starting this phase).
- shopify.app.toml: this org appears enrolled in Shopify's "Next
Generation Events" developer preview, which the CLI now treats as a
REQUIRED top-level [events] section even though nothing in this app
actually uses it (real webhook handling is entirely classic [webhooks],
unaffected). Iteratively discovered the required shape from the CLI's
own field-by-field validation errors, then found the real docs (Events
is optional/developer-preview, api_version pinned to "unstable") to
confirm rather than keep guessing. Added a functionally-inert
[[events.subscription]] placeholder + a stub handler
(webhooks.events.placeholder.tsx) solely to satisfy the gate.
- app/services/availability-request.server.ts +
app/services/hold-request.server.ts: extracted the resolution logic that
used to live directly in apps.scheduling.availability.tsx/hold.tsx into
shared functions. This is what actually makes "same capacity pool feeds
every surface" (CLAUDE.md) true by construction rather than by
convention — the storefront, POS, and checkout routes now call the exact
same code, not three copies that could quietly drift apart.
- extensions/pos-datetime (generated via `shopify app generate extension
--template=pos_smart_grid` — pos_action's flavor requirement contradicted
the CLI's own global --flavor validator, so smart_grid was used instead):
a home-screen tile opening a modal where staff pick method -> date -> time
against the same availability/hold endpoints (pos.scheduling.*.tsx,
session-token authenticated), writing the same dd_* cart properties via
CartApi.addCartProperties — booking.server.ts needed zero changes to
handle POS-originated orders. Several API-shape guesses (toast isError
option, ChoiceList's `value`/`label` props, a nonexistent
action.dismissModal(), shopify.cart.cart.current) were wrong and caught
by typechecking directly against @shopify/ui-extensions' own bundled
.d.ts files (`npm run typecheck:pos`, now also in CI) — none of this was
verified against a live POS session, which isn't possible in this
environment.
- extensions/checkout-datetime (generated via `--template=checkout_ui`):
the Plus-only native picker in checkout itself
(purchase.checkout.block.render) plus a Thank You confirmation block
(purchase.thank-you.block.render). Went looking for an order-status
target too ("all plans show confirmed slot on thank-you/order-status" is
the Phase 7 accept criterion) and confirmed via the installed package's
own type definitions that purchase.order-status.block.render does not
exist in this API version — checkout UI extensions' thank-you/order-status
surfaces are Plus-only regardless. The actual "all plans" mechanism is
extensions/datetime-widget/blocks/order-confirmation.liquid — a new Theme
App Extension block reading order.note_attributes, which works on every
plan since it's plain Liquid, not checkout extensibility.
Both new UI extensions share one real unverified assumption, called out in
code comments: process.env.APP_URL is expected to be substituted at build
time by the Shopify CLI to the app's backend origin, since these run in a
different origin than the app and need an absolute URL, unlike the
storefront widget's relative /apps/scheduling/* path. Needs confirming
against a live dev session.
Verified: lint, typecheck (root + both new extensions'
`npm run typecheck:pos`/`typecheck:checkout`, all now in CI), 102 unit +
18 integration tests (unchanged — this phase didn't touch pure business
logic, only added thin auth wrappers around already-tested services), both
admin/widget builds.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
|