2.2

The middleware couldn't capture the HTTP calls an integration sends and play them back, so running an integration meant reaching a live platform.

defineMocker in @alokai/connect/integration-kit returns an extension and a programmatic handle. It intercepts the outgoing HTTP calls of your integrations and can record or replay them. When you register it, it also mounts five unauthenticated GET routes on your middleware.

AppError strips trailing digits from the class name it reports in error.name. A bundler that renames HttpError to HttpError2 no longer leaks that name into error.name.

@alokai/connect lists nock, @mswjs/interceptors, and fast-json-stable-stringify as runtime dependencies. They back defineMocker.

A normalizer failure was a bare sentence that didn't say which normalizer ran or what it received. When another error carried it as its cause, even its Zod issues were lost.

A ValidationError from a normalizer now carries the input it received and the normalizer key it failed in. It keeps its original issues, and its message links to the guide on overriding normalizers. AppError.toJSON() serializes a nested AppError cause through that cause's own toJSON().

Normalizer validation errors now carry the platform input they failed on, and that error is the body the middleware sends back. So the input leaves the middleware too.

A ValidationError resolves to HTTP 400, and the built-in error handler sends error.toJSON() as the body for any status below 500. That body now includes data.input, the whole unnormalized platform object for the entity that failed.

The old log lines said what the circuit breaker did, not what it meant for you. Two of them also logged at a severity that didn't match what happened.

Every circuit breaker log message has new text, and two change severity:

• Circuit breaker FAILURE for <key> becomes Circuit breaker observed an upstream error for <key> - ... and drops from error to warning.
• Circuit breaker REJECTED request for <key> becomes Circuit breaker blocked a request for <key> - ... and rises from info to warning.
• Circuit breaker OPENED for <key> becomes Circuit breaker OPEN for <key> - ....
• Circuit breaker HALF-OPEN and Circuit breaker CLOSED keep their opening words and gain a tail, so a search for either still matches.
• Created circuit breaker for <key> becomes Circuit breaker created for <key> - ..., so a search for the old text no longer matches.

Each event's metadata also has an impact field (observing, blocking, probing, or recovered) and a recommendedAction field (investigate_upstream or none).

In production, the middleware logged that it was falling back from EXTREME_DEBUG to BALANCED, and then kept EXTREME_DEBUG anyway.

When NODE_ENV is production, the EXTREME_DEBUG preset falls back to BALANCED, as the log always said it did.

A vulnerability in what the middleware could write to your logs has been identified and fixed.

The middleware redacts the metadata of every log it writes, not only the circuit breaker's. A value becomes [REDACTED] when its key contains authorization, cookie, password, passwd, secret, token, credential, or apikey / api-key / api_key, in any case. The exact keys _header, _httpMessage, and outputData are redacted too.

Metadata is also capped in depth, string length, and array and object width. You can add keys to the list with redactKeys in the logger block of your middleware config, but you can't remove a built-in one.

A broken extension export failed with TypeError: fnToExecute is not a function, which didn't say what broke. A transport error behind a normalized message never reached the log at all.

An API method that isn't a function now throws an AppError that names the extension and the function. The circuit breaker's failure log metadata includes the error's whole cause chain, so an ECONNRESET behind an HttpError reading Failed to communicate with external service is visible.

Errors of status 500 and above raised while the middleware prepares the API method are logged through the Alokai logger. The client gets the generic ServerError: Something went wrong. Please, check the logs for more details. Errors in the 4xx range keep their own message and aren't logged.

The middleware exports middleware_circuit_breaker_state_by_key (1 closed, 0.5 half-open, 0 open) and middleware_circuit_breaker_failure_rate (0-100 over the rolling window). Both are labelled by integration and key, next to the existing per-integration middleware_circuit_breaker_state. The failure rate updates on every counted upstream error, not only on a state change.

CircuitBreakerError has a fixed message instead of the underlying library's text: Upstream temporarily unavailable for <key> - the circuit breaker is open and is failing requests fast to protect the upstream; retry shortly.

The CMS mock's route maps follow the new /c/ and /p/ URLs, but the page layout that serves those URLs doesn't reach an existing project. A project still on /category/ asks the mock for paths it no longer maps.

@vsf-enterprise/cms-mock-api 4.0.1 repoints its SAP Commerce Cloud and B2B route maps from /category{/*id} and /product/:id/:sku to /c{/*id} and /p/:id/:sku. Every mock banner and hero link moves from /category/... to /c/....

Alokai's two injected scripts loaded before the page became interactive, which put them on the critical path of every page load.

@vue-storefront/next and @alokai/instrumentation-next-component load their injected scripts with the afterInteractive strategy of next/script instead of beforeInteractive. The @vue-storefront/next script, alokaiEnv, sets window.__ALOKAI_ENV__, the only source env() reads in the browser. AlokaiProvider creates that script only during the server render, and Next.js adds an afterInteractive script from the client render, so on this version it never reaches the page.

Your client bundle carried the legacy polyfills for flatMap, Object.entries, and similar that Turbopack adds by default, and the generated config didn't turn them off.

A newly generated Next.js app ships apps/storefront-unified-nextjs/modern-polyfill.js, an effectively empty module. A turbopack.resolveAlias block in next.config.mjs points Next's polyfill-module at it. The generated components/cms/page/banner.tsx computes its image attributes once through getImageProps from next/image and requests quality: 45.

On 2.2.2, browser code that called env('NEXT_PUBLIC_...') got undefined. 2.2.2 moved the alokaiEnv script to afterInteractive, and that move stopped the script from being injected at all.

The alokaiEnv script that AlokaiProvider renders loads with the beforeInteractive strategy of next/script again. Next.js puts a beforeInteractive script into the initial HTML and runs it before your own client code. The runtime values are in place before your first render.

On 2.2.2, the script that installs the analytics history trace loaded after hydration instead of before it, so it missed the first page view.

The history-trace script that AlokaiInstrumentation renders loads with beforeInteractive again instead of afterInteractive. The history trace is installed before hydration.

A vulnerability in Next.js was found and fixed in the May 2026 Next.js security release. Your storefront keeps running the old Next.js until the pin that selects it moves.

The generated storefront's apps/storefront-unified-nextjs/package.json pins next at 16.2.6 instead of 16.1.6.

The commercetools and Magento custom-queries guides lead with a custom API method that tags its query with gql from graphql-tag and starts the template literal with a /* GraphQL */ comment. With the GraphQL extension, your editor highlights the query's syntax. If you point the extension at your schema through a graphql.config.yaml at the project root, it also autocompletes against the schema.

The customQuery route keeps its plain string, with a leading #graphql comment, because a string passed to a method can't be tagged.

The search-bloomreach installer targeted the old category and product page layout, and when it couldn't find a pattern it expected, it wrote a half-modified file and carried on.

The search-bloomreach installer targets the new sf-modules/category and sf-modules/product layout, and throws when a pattern it expects is missing. baseCmsSchemas writes your CMS catch-all page as a one-line re-export of the adopted module. On a SAP Commerce Cloud or SAP Commerce Cloud B2B store, a teardown hook rewrites the category and product route patterns. baseNextjsAppSchemas and baseNuxtPagesSchemas are removed from the package's exports.

The deployed image tag was always the git commit SHA, so redeploying the same commit meant creating an empty commit.

store deploy gains --docker-image-tag, also readable from CLI_DOCKER_IMAGE_TAG. The build, push, and trigger steps all use the same tag. Deployment composition skips the frontend app that doesn't match the store's deployment.framework.

vitest moves from 2.1.9 to 4.0.18 in a freshly generated apps/storefront-middleware/package.json.

All four packages move from tinyexec@^0.3.1 to ^1.0.2. That resolves the tinyexec version conflict that made a global CLI install fail with MODULE_NOT_FOUND.

The @vsf-enterprise/module-kit cleanup removes both the @/sf-modules/cms-mock and the @sf-modules-middleware/cms-mock import forms. It also removes the 'cms-mock': cmsMockConfig entry and the unified-cms-mock SDK re-export, even when they don't match the generated text exactly.

cms-mock is no longer in the CLI's module catalogue, so add-module cms-mock doesn't resolve to a module.

In @vsf-enterprise/storefront-cli 3.3.0, the tsconfig files generated for Next and Nuxt module directories take their references from the tsconfig references of the .out apps.

The interactive menu gains a "Refresh .env files" option. It copies .env.example to .env and restarts the server. With --use-store-source-env, it uses the store's source .env.example instead of the one the install script modified.

modifyFile in @vsf-enterprise/file-modifier 4.0.1 creates missing parent directories for an outputPath instead of failing.

Compass had two factories, defineTool and defineDynamicTool, for one job, and both took a single object with the callback inside it.

defineDynamicTool is gone, and defineTool(config, callback) replaces both factories. It takes two arguments where 2.1.3 took one object. Workflow.startingPrompt is renamed workflowPrompt, and AnalyticsActionConfig collapses to { type: 'analytics' }.

createGenrativeUiComponent is renamed createGenerativeUiComponent. The scripted and parallel transition variants leave the union. Two runtime behaviors change with no code to port: every LLM invocation is size-checked, and an image_url that isn't a data: URL is rejected.

The heavy model slot moves from GPT-4.1 to GPT-5-chat. The medium slot moves from GPT-4.1-mini to GPT-5-mini. The light slot stays on gpt-4o-mini. The guided selling prompts are updated for GPT-5-chat.

Compass can compact the chat history. It summarizes older messages and keeps the recent context. You opt in with useCompactHistory on the assistant hook, or pass it as an SDK parameter. The rolling summary is kept in the browser's localStorage.

You tune the compactor per workflow with compactor.summarizationThreshold ("small", "medium", or "large"), compactor.slidingWindow, and compactor.filterEntry.

An image analysis action describes the images in a conversation. The descriptions go into both the full and the compacted chat history.

transformMessageContent gives you the content of each non-system message, one at a time, before it reaches the LLM. You can trim it, for example a generative-UI payload, or return null to drop the message. A crash in the analytics action's own trimming of message content is fixed.

A workflow takes a payload through Workflow.payloadSchema. The payload reaches a tool's schema, callback, and cache.key as params.workflowPayload. It also reaches the new shouldEnableTool predicate the same way.

A workflow can send patches to the storefront's own state management. The frontend half is the ai-controlled-state context in the Compass module.

Streaming and non-streaming responses both carry API usage metadata: token counts and model info.

Compass streams the Set-Cookie headers from commerce API responses to the browser. Compass's SDK sets them there with document.cookie, which can't set an HttpOnly cookie, so a tool that sets one during a streamed call throws an error naming the cookie.

The chatbot workflow gains a tool that removes several cart line items at once and a tool that clears the cart. getCart returns the cart itself, so the LLM can find line item IDs.

Product search is part of the main assistant action. The module's workflow no longer has a separate search-products router step, and the category enum strategy in the searchProducts tool schema changes to match. Compactor tool-call summaries are tighter, so the LLM stops inventing IDs and SKUs.

A synchronous invoke returned only the last message a workflow produced, not all of them. Each request also rebuilt the workflow from scratch.

Compass compiles a workflow once and reuses it across requests. A synchronous (non-streaming) invoke returns every message the workflow produced.

Most of the Compass module's own source moved. The new source has a guided selling page with configure and search tabs, an AI canvas, and the ai-controlled-state context, which is the frontend half of state patches. The module declares three new frontend dependencies: @rjsf/core, @rjsf/utils, and @rjsf/validator-ajv8.

useAssistant's sendMessage changes from variadic sendMessage(...messages) to sendMessage(messages, options). It defaults useCompactHistory to true.

@alokai/cli-plugin-compass 1.1.3 re-pins zod to ^4.1.12.

SAP Commerce Cloud uses /c/ and /p/ for its category and product URLs, but the storefront served /category/ and /product/ instead.

Newly generated SAP Commerce Cloud and SAP Commerce Cloud B2B storefronts serve product listing pages under /c/... and product detail pages under /p/....

In the Next.js app, the app/[locale]/(default)/category and product route folders become c and p. The page logic moves into sf-modules/category/ and sf-modules/product/. config/routes.ts adds typed categoryPage/productPage builders, and config/navigation.ts swaps its patterns and gains a resolvePathname helper. Per-module json-ld.ts files replace helpers/generate-json-ld.ts.

A new config/rewrites.config.mjs, wired into next.config.mjs as rewrites, strips SAP's breadcrumb prefix, so /Collections/Streetwear/c/streetwear becomes /c/streetwear. The Nuxt app gets the equivalent under sf-modules/ plus utils/routes.ts.

Customer login used only the resource-owner password flow (ROPC).

@vsf-enterprise/sapcc-api 11.1.0 adds OAuth Authorization Code with PKCE for customer login. At middleware init, it probes <OAuth.uri>/oauth/authorize with a 5 second timeout to detect PKCE support, and falls back to ROPC when the probe fails.

MiddlewareOAuthConfig gains an optional redirectUri. OAuth.pkceSupported forces one flow or the other and skips the probe.

If an interceptor on the default axios export adds something your SAP traffic needs, such as a proxy agent, a client certificate, or a required header, the PKCE support probe no longer gets it, and you silently lose PKCE.

The PKCE support probe runs on a dedicated axios.create({ baseURL }) instance instead of the default axios export. That instance picks up axios.defaults but not the interceptors registered on the default export. The probe runs once at middleware start. On any failure, it falls back to ROPC and logs Failed to detect PKCE support. Falling back to ROPC. Set OAuth.pkceSupported explicitly to avoid startup auto-detection. at warning level.

A PKCE authorization redirect that carries a bare ?error with no value counts as an authorization failure. The storefront still gets a 401, as before. The message changes from Failed to obtain authorization code from PKCE flow to PKCE authorization failed: unknown error.

Right after login and a guest-cart merge, a B2B shopper could get a stale or wrong cart, or the storefront fell back to a fresh empty cart.

B2B post-login cart resolution calls SAP CC's getCurrentOrgCart endpoint instead of listing carts with getCarts. loginCustomer writes the org cart's code into the unified-cart-id cookie, so later requests target the right cart. B2B also gets its own getCart, built on the same lookup.

Under Node ESM, new SdkAuth() threw. @commercetools/sdk-auth is a CommonJS package, and a default import from ESM returned the module object instead of the constructor.

The integration resolves the CommonJS default export of @commercetools/sdk-auth before it calls it. @vsf-enterprise/commercetools-api declares "type": "module" at both 8.0.0 and 8.0.1.

@vsf-enterprise/magento-api 9.0.1 imports CustomQuery from @alokai/connect/middleware. The CustomQuery export in @vsf-enterprise/magento-types 4.0.3 is deprecated but still present. @vsf-enterprise/unified-api-magento 6.0.2 requires @vsf-enterprise/magento-types at exactly 4.0.3 and @vsf-enterprise/magento-api at ^9.0.1.

When you edited a different draft, the storefront kept rendering the first one. initLivePreview read the live preview hash only once, when it initialized.

initLivePreview re-reads the Contentstack live preview hash on every edit and writes it into the vsf-live-preview-query search parameter. It passes the result, the current path plus that query, to your onLiveEdit callback as its first argument, livePreviewUrl. The callback type widens to (livePreviewUrl?: string) => Promise<void> | void.

The callback in the Contentstack CMS module's Next.js live-preview.tsx navigates with router.replace(livePreviewUrl) instead of router.refresh().

Nested fields weren't clickable in Contentstack Visual Builder, while top-level fields were. The camelCase conversion turned the $ key that holds a nested prop's Visual Builder metadata into an empty string.

normalizeComponentProp in the module's Next.js render-cms-content.tsx takes the $ key out of a nested prop before the camelCase conversion and puts it back unchanged after it.

Without a / entry in your route map, the root route served the fallback page instead of your SmartEdit homepage.

cms-smartedit maps / to pageLabelOrId: 'homepage' by default in resolvePages. SmartEdit's own "homepage" label resolves on the root route without configuration.

@vsf-enterprise/smartedit-api 6.1.0 adds a getComponents method that fetches specific components by ID without a full page request. A new resolveUnknownComponents callback on UnifiedConfig handles references the standard component lookup doesn't return, such as components on a custom endpoint like /story-book/items. Both go through the same reference resolution and normalization as getPage.

The getDepthLevelForComponent callback also receives methodParams, the original arguments passed to getPage or getComponents. Depth can vary per page or per request.

The bundled type declarations in @vsf-enterprise/smartedit-sdk 3.0.1 reference axios.AxiosResponse again. Earlier builds had undefined in its place.

If you registered addCustomFields.normalizeProductCatalogItem - Compass does, with a required description: string - the SmartEdit module's product references failed typecheck with a $custom mismatch.

The SmartEdit CMS module's getProductReferences normalizes each reference's target with normalizeProductCatalogItem instead of normalizeProduct. That matches the SfProductCatalogItem type that ProductCardVertical expects.

You configured Bloomreach Discovery in two places: the resolvers in createUnifiedExtension({ config }), and the settings they resolve against in the middleware configuration.

8.0.0 moves resolveDomainKey, resolveViewId, and resolveTrackingParams out of createUnifiedExtension({ config }) and into the middleware configuration block, beside discoveryApi. facetVersion, currencies, and the product field list move under discoveryApi.search, and facetFields is renamed to productFields. Each sub-API (search, autosuggest, bestseller, contentSearch, emailWidget, recommendationsPathways) takes an optional basePath, which replaces the removed discoveryApi.environment and top-level discoveryApi.basePath.

You can pass efq and userId per request through searchProducts params. You can set efq, statsField, and currencies globally under discoveryApi.search.

A normalizeFacet override and addCustomFields apply to legacy text, range, and category facets, not only to v3 ones. Category and price facets are no longer dropped under facetVersion: "3.0". Legacy category fields are detected by value shape rather than by field name.

NormalizeFacetInput, AddCustomFields, and InferAddCustomFields are exported for overrides and module augmentation. getProductDetails reads productFields from discoveryApi.search, so a custom catalog attribute such as price_range reaches addCustomFields.

A project that adopts the module after this release sends its production search to Bloomreach staging.

The search-bloomreach module's installer is rewritten. The SAP Commerce Cloud configuration block it injects carries basePath: 'https://staging-core.dxpapi.com/api/v1/core', which is Bloomreach's staging search host.

The generated project's .github/actions/setup/action.yml runs npm config set "@vsf-enterprise:registry=..." and npm config set "@alokai:registry=..." after npm-cli-login. A checkout without the project's own .npmrc can then still resolve private packages.

In a newly bootstrapped project, .github/workflows/continuous-delivery.yml still reads secrets.CONSOLE_API_URL first, and falls back to https://api.console.alokai.com instead of to vars.CONSOLE_API_URL, which it no longer reads.