Skip to main content

@acromedia/gesso-shopware

8.4.0​

Minor Changes​

  • c309ece: @acromedia/gesso-shopware: Adds the useCustomer plugin implementation via the Store API (/store-api) — profile, address book, and registration. login, logout, exists, and password.passwordResetEmail/passwordReset are implemented directly on useCustomer (duplicated from useAuth's Store API calls), so the hook works standalone without also configuring Shopware's useAuth as the commerce provider's authPlugin.

    Adds the shopwareSalesChannelDomain config key (NEXT_PUBLIC_SHOPWARE_SALES_CHANNEL_DOMAIN), the domain Shopware builds registration and recovery links from. It replaces shopwareRecoveryStorefrontUrl, which is now deprecated but still read as a fallback. useCustomer().add and useAuth().password.passwordResetEmail now throw when neither key is set, instead of falling back to window.location.origin or shopwareStorefrontUrl.

8.3.0​

Minor Changes​

  • 2ccc25a: Implement Shopware authentication (useAuth).

    @acromedia/gesso-shopware replaces the useAuth stub with the full auth surface on Shopware's public Store API account routes: login (POST /account/login, then POST /account/customer), logout, password.passwordResetEmail (recovery-password), and password.passwordReset (recovery-password-confirm). Login returns the rotated sw-context-token on the customer as options.accessToken — the same slot BigCommerce uses for its customer access token, and the field GessoAuthOptions copies onto the next-auth JWT — so a login performed server-side inside authorize carries its Store API session forward. Logout drops the gesso-sw-context cookie so the next visit opens a clean guest session. Adds the optional shopwareRecoveryStorefrontUrl and cookieName config keys.

    @acromedia/gesso-shopware-middleware adds the exists action — an Admin-API account-exists probe (GET /api/middleware/shopware/exists?email=) that answers with the bare customer id or a 404, backing useAuth.exists and next-auth's GessoAdapter.getUserByEmail. It returns only the id, so an email-keyed probe cannot expose a customer's name, addresses, or order history. getContextToken now also reads the token from the JWT's accessToken key, where GessoAuthOptions stores it by default.

Patch Changes​

  • 6b9207e: Checkout now lists only shipping methods that are actually available — the onlyAvailable flag was being sent in the request body, where Shopware ignores it; it belongs in the query string.

    Store API calls made through the exported storeClient/StoreApiClient are now type-checked against the real operation contracts (they were silently any before). If your app invokes the client directly, previously-compiling calls with invalid bodies or operation names will surface type errors on upgrade — each one is a request Shopware was already rejecting or ignoring at runtime.

  • Updated dependencies [53f7971]

    • @acromedia/gesso-core@8.3.0

8.2.0​

Minor Changes​

  • 43dcc1a: fix useProductSearch implementation. Return all products when no category or keyword is passed.
  • 43dcc1a: Register the visitor as a guest customer when no authenticated session - Shopware

Patch Changes​

  • Updated dependencies [8afcce4]
    • @acromedia/gesso-core@8.2.2

8.1.0​

Minor Changes​

  • 0d108e1: feat: checkout hook with order placement and payment redirect

    Implement the Shopware checkout against the Store API, satisfying the @acromedia/gesso-commerce useCheckout contract. Both checkout modes ship behind one hook, branching on the payment response at runtime:

    • placeOrder runs POST /store-api/checkout/order then POST /store-api/handle-payment (with orderId + finishUrl/errorUrl) and branches on the response redirectUrl — null is a sync/on-site method (invoice/COD) that goes straight to confirmation; a string is an async/off-site method (PayPal/card) that the hook redirects out to and that returns the shopper at finishUrl/errorUrl. redirectedCheckout is derived from the runtime response, never hard-assumed.
    • get composes the pre-placement order context from the active cart, enriched with the sales-channel's available payment and shipping methods.
    • Billing/shipping/payment selection is applied to the sales-channel context via PATCH /store-api/context; address creation and guest registration remain with the customer/auth hooks.
    • New config: shopwareCheckoutFinishUrl, shopwareCheckoutErrorUrl, and an onCheckoutRedirect navigator (defaults to window.location.assign).
    • Vitest specs with MSW fixtures covering order placement and both branches of the payment-handling step.

  • 0d108e1: shopware orders plugin

  • 0d108e1: feat: cart lifecycle hook and server getter

    Implement the full Shopware cart against the Store API (/store-api/checkout/cart and /checkout/cart/line-item):

    • useCart satisfying the @acromedia/gesso-commerce contract — get (create-on-read), add, update, and remove — wired through both the client hook and the SSR getCart getter.
    • Promotions are applied as Shopware promotion line items (add(code, qty, { type: 'promotion' })) and removed by line-item id; applied promotions are surfaced under cart.data.promotions.
    • A Shopware→Gesso cart normalizer producing items plus summary adjustments (quantity / subtotal / discount / total).
    • The rotating sw-context-token is preserved across mutations via the shared Store API client, so a guest cart survives subsequent reads and mutations.
    • Vitest specs with MSW fixtures covering the lifecycle (including promotions and context-token rotation), plus opt-in live-sandbox checks.

  • 0d108e1: GESSO-2428-feat: add Shopware 6 commerce plugin

    New @acromedia/gesso-shopware package implementing the @acromedia/gesso-commerce hook surface (useCatalog, useProduct, useProductSearch, useFacet, useCart, useCustomer, useCheckout, useOrders, useAuth) on top of Shopware's REST Store API (/store-api).

    • The read paths — useCatalog, useProduct, useProductSearch, useFacet — are implemented. The write paths (useCart, useCustomer, useCheckout, useOrders, useAuth) are present as typed stubs and land in follow-up tickets.
    • Talks to the Store API through the official @shopware/api-client SDK (pinned), wrapped in a thin StoreApiClient — mirroring how gesso-shopify wraps @shopify/graphql-client. Hooks call its fully-typed invoke(...), and request/response types come from the SDK's bundled store-api-types.
    • Reads connection settings from gesso.config.json (generated from .env via the plugin CLI): requires shopwareStorefrontUrl and the public sales-channel sw-access-key; optional shopwareCurrencyCode, shopwareLanguageId, shopwareCurrencyId, and shopwareRootCategoryId.
    • Captures the rotated sw-context-token via the SDK's onContextChanged hook and persists it through a pluggable ContextTokenStore — a cookie in the browser, a no-op (anonymous) on the server, and injectable for request-scoped SSR.
    • Ships as an ESM-only package built with tsc; unit-tested with Vitest (Store API mocked with MSW).

  • 0d108e1: feat: catalog, product, search and faceted navigation

    Implement the storefront catalog surface for the Shopware plugin:

    • useProduct / useCatalog / useProductSearch / useFacet hooks satisfying the @acromedia/gesso-commerce contracts, surfaced through the SSR getters (getProduct / getCatalog / getProductSearch).
    • A Criteria translator mapping Gesso keyword/sort/page/facet/price inputs onto Shopware listing criteria (order / p / limit / manufacturer / properties / min-price / max-price), adding facet filtering and cursor-based pagination to search and category listings.
    • A Shopware→Gesso normalizer for products, categories and listing aggregations.
    • Vitest specs with MSW fixtures, plus opt-in live-sandbox smoke tests.

Patch Changes​

  • Updated dependencies [cd5a6d5]
    • @acromedia/gesso-core@8.2.1