@code-collective/booking-widget 1.0.16 → 1.0.17

package/CHANGELOG.md

@@ -1,75 +1,86 @@
-# Changelog
-
-The version in `package.json` had drifted behind npm (the repo said 1.0.7 while `latest` was 1.0.9), so
-1.0.8 and 1.0.9 shipped without an entry here. This file starts at the point that caused a consumer a real
-detour.
-
-## 1.0.16
-
-Peach now owns payment retries. A declined card never reaches the widget or the checkout API at all - Peach
-re-prompts inside its own embedded form and the shopper returns only once they have paid or given up - so the
-widget no longer reports declines, no longer asks the server to go and read Peach's status, and no longer
-renders a decline screen of its own.
-
-- **Removed** `reportPaymentFailure()` and `resolvePayment()` from `BookingApi`/`ApiClient`. The endpoints
-  behind them (`POST /v1/checkout/cart/payment-failure`, `POST /v1/checkout/cart/resolve-payment`) are gone
-  from the checkout API. Anything calling them directly must drop the call; there is nothing to replace it
-  with, because there is no longer a client-reported outcome for the server to record.
-- **Changed** the cart status response is now `{ cartStatus, confirmResult }`. `paymentOutcome`, `resolvedBy`
-  and `resultCode` are gone - the browser reads the cart's own status and nothing else.
-- **Changed** a Peach SDK `error` or `expired` callback now releases the checkout through
-  `abandonPayment()`, the same call a cancel already used, so Try Again always mints a brand-new Peach
-  checkout rather than reopening one Peach has finished with.
-- **Fixed** a cart the server's stuck-payment sweep expired is terminal in the widget. It used to keep
-  polling a cart that could never change until the poll's own 90s window ran out, and a reload landed the
-  shopper back on a card form for a cart that no longer existed.
-- **Unchanged** every export, custom-element attribute, `bwOptions` key and `bw:*` event name.
-
-## 1.0.13, 1.0.14, 1.0.15
-
-Published without entries here. 1.0.13 and 1.0.14 carried a CSS regression - the checkout modal's own styles
-(cart card, pay bar, buttons) were silently missing from the built widget after a CSS split - and **1.0.15
-fixes it**. Anyone pinned to 1.0.13 or 1.0.14 should upgrade.
-
-## 1.0.12
-
-Published from the branch that carries this work, which 1.0.10 was not. 1.0.11 was prepared but never
-published - the release script bumps patch before publishing, so the version that went out is one ahead of
-the one the branch was prepared as. The contents are identical either way.
-
-## 1.0.10
-
-Published from a checkout that did not contain this work - `npm run release` was run from the main repo
-while the branch lived in a worktree - so it carries none of the entries below. `createBookingHost`,
-`BookingProvider`, `CartExpiryGuard`, `portal` and `setPeachSdk` are all absent from its `src/lib/index.ts`,
-which is the entry the `svelte` export condition points at and therefore the one a Svelte consumer compiles.
-Nothing to roll back; it is 1.0.9's code under a new number. **Publish from a checkout that has the branch,
-and check the entry exports before shipping** - `npm pack` the tarball and grep `package/src/lib/index.ts`.
-
-See `.changeset/` for the individual entries. In summary:
-
-- **Added** `createBookingHost()`, the shared host layer both builds now wire through, and
-  `BookingProvider` so components need no `api`/`cartManager` props.
-- **Added** `mode="modal"` on `Checkout`, portalled to `document.body`.
-- **Added** exports: `CartExpiryGuard`, `onWidgetMessage`, `postMessage`, the `WidgetMessage` union,
-  `portal`, `setBookingDefaults`.
-- **Changed** add-to-cart now opens checkout on every build by default (`autoOpenCheckout`).
-- **Changed** each `bw:*` event reaches `window` once per thing that happened. They were arriving twice,
-  and `bw:close` four times per dismissal. Anything counting `bw:order-confirmed` was double-counting.
-- **Changed** each `bw-*` element dispatches its own events rather than all firing on the first element of
-  that tag.
-- **Fixed** building a host no longer throws `window is not defined` during a server render.
-- **Unchanged** `ApiClient`, `SessionManager` and `CartManager` are still exported; the custom-element
-  attributes, `bwOptions` and the `bw:*` event names are all as they were.
-
-## 1.0.9
-
-- **Removed** `FakeApiClient` and the `useFakeApi` mount option, along with `src/lib/fake-api.ts`. This was
-  a breaking change shipped in a patch release with no note: a consumer importing `FakeApiClient` gets a
-  build error, because a missing named export is a hard failure in a bundler, not a runtime `undefined`.
-  It had been the offline development path for consumers with no checkout API configured.
-
-  **Decision: removed for good.** It is not coming back, and no later version reinstates it. A consumer
-  that wants to run without a checkout API should render its own fallback rather than a fake catalogue.
-  Where a stand-in client is genuinely needed - a test double, a demo page - pass one to
-  `createBookingHost({ api })`, which takes any `BookingApi` implementation.
+# Changelog
+
+The version in `package.json` had drifted behind npm (the repo said 1.0.7 while `latest` was 1.0.9), so
+1.0.8 and 1.0.9 shipped without an entry here. This file starts at the point that caused a consumer a real
+detour.
+
+## 1.0.16
+
+Peach now owns payment retries. A declined card never reaches the widget or the checkout API at all - Peach
+re-prompts inside its own embedded form and the shopper returns only once they have paid or given up - so the
+widget no longer reports declines, no longer asks the server to go and read Peach's status, and no longer
+renders a decline screen of its own.
+
+- **Removed** `reportPaymentFailure()` and `resolvePayment()` from `BookingApi`/`ApiClient`. The endpoints
+  behind them (`POST /v1/checkout/cart/payment-failure`, `POST /v1/checkout/cart/resolve-payment`) are gone
+  from the checkout API. Anything calling them directly must drop the call; there is nothing to replace it
+  with, because there is no longer a client-reported outcome for the server to record.
+- **Changed** the cart status response is now `{ cartStatus, confirmResult }`. `paymentOutcome`, `resolvedBy`
+  and `resultCode` are gone - the browser reads the cart's own status and nothing else.
+- **Changed** a Peach SDK `error` or `expired` callback now releases the checkout through
+  `abandonPayment()`, the same call a cancel already used, so Try Again always mints a brand-new Peach
+  checkout rather than reopening one Peach has finished with.
+- **Fixed** a cart the server's stuck-payment sweep expired is terminal in the widget. It used to keep
+  polling a cart that could never change until the poll's own 90s window ran out, and a reload landed the
+  shopper back on a card form for a cart that no longer existed.
+- **Fixed** a card Peach ultimately declined used to leave the shopper on the verifying spinner for its full
+  90 seconds and then on the pending screen, never offered Try Again, for a cart that could never change.
+  Peach fires its completed callback for a rejected transaction as well as a charged one; the widget now reads
+  the result code it carries and resolves straight to Payment Failed with Try Again. It deliberately does not
+  ask the server: Peach's checkout-level status answers "transaction pending" for a rejected transaction, so
+  it is only good for confirming a success. A code the widget cannot read is still treated as a possible
+  charge and polled, since showing "Payment Failed" over a charged card is the worse error.
+- **Changed** Pay Now is accepted on a cart still awaiting confirmation, minting a new checkout over the dead
+  one. Nothing about the cart changes - that is what makes Try Again work after a decline. The new checkout
+  reuses the cart's merchant order ID, so Peach's dashboard still shows one order per basket however many
+  times the shopper retried; editing the basket is what mints a new order ID.
+- **Unchanged** every export, custom-element attribute, `bwOptions` key and `bw:*` event name.
+
+## 1.0.13, 1.0.14, 1.0.15
+
+Published without entries here. 1.0.13 and 1.0.14 carried a CSS regression - the checkout modal's own styles
+(cart card, pay bar, buttons) were silently missing from the built widget after a CSS split - and **1.0.15
+fixes it**. Anyone pinned to 1.0.13 or 1.0.14 should upgrade.
+
+## 1.0.12
+
+Published from the branch that carries this work, which 1.0.10 was not. 1.0.11 was prepared but never
+published - the release script bumps patch before publishing, so the version that went out is one ahead of
+the one the branch was prepared as. The contents are identical either way.
+
+## 1.0.10
+
+Published from a checkout that did not contain this work - `npm run release` was run from the main repo
+while the branch lived in a worktree - so it carries none of the entries below. `createBookingHost`,
+`BookingProvider`, `CartExpiryGuard`, `portal` and `setPeachSdk` are all absent from its `src/lib/index.ts`,
+which is the entry the `svelte` export condition points at and therefore the one a Svelte consumer compiles.
+Nothing to roll back; it is 1.0.9's code under a new number. **Publish from a checkout that has the branch,
+and check the entry exports before shipping** - `npm pack` the tarball and grep `package/src/lib/index.ts`.
+
+See `.changeset/` for the individual entries. In summary:
+
+- **Added** `createBookingHost()`, the shared host layer both builds now wire through, and
+  `BookingProvider` so components need no `api`/`cartManager` props.
+- **Added** `mode="modal"` on `Checkout`, portalled to `document.body`.
+- **Added** exports: `CartExpiryGuard`, `onWidgetMessage`, `postMessage`, the `WidgetMessage` union,
+  `portal`, `setBookingDefaults`.
+- **Changed** add-to-cart now opens checkout on every build by default (`autoOpenCheckout`).
+- **Changed** each `bw:*` event reaches `window` once per thing that happened. They were arriving twice,
+  and `bw:close` four times per dismissal. Anything counting `bw:order-confirmed` was double-counting.
+- **Changed** each `bw-*` element dispatches its own events rather than all firing on the first element of
+  that tag.
+- **Fixed** building a host no longer throws `window is not defined` during a server render.
+- **Unchanged** `ApiClient`, `SessionManager` and `CartManager` are still exported; the custom-element
+  attributes, `bwOptions` and the `bw:*` event names are all as they were.
+
+## 1.0.9
+
+- **Removed** `FakeApiClient` and the `useFakeApi` mount option, along with `src/lib/fake-api.ts`. This was
+  a breaking change shipped in a patch release with no note: a consumer importing `FakeApiClient` gets a
+  build error, because a missing named export is a hard failure in a bundler, not a runtime `undefined`.
+  It had been the offline development path for consumers with no checkout API configured.
+
+  **Decision: removed for good.** It is not coming back, and no later version reinstates it. A consumer
+  that wants to run without a checkout API should render its own fallback rather than a fake catalogue.
+  Where a stand-in client is genuinely needed - a test double, a demo page - pass one to
+  `createBookingHost({ api })`, which takes any `BookingApi` implementation.