1.3

The middleware always passes a logger to every hook, but the type marked it optional. So you had to write logger?. or a non-null assertion to log through it.

HookParams in @alokai/connect/middleware now declares logger: LoggerInterface instead of logger?: LoggerInterface. Nothing runs differently - only the type declarations change.

From here on, new components and examples assume Storefront UI 3 on React. Where the reference storefront has gone decides whether your own app can take them.

apps/storefront-unified-nextjs moves to @storefront-ui/react 3 and adds framer-motion, across 88 files. The Nuxt app stays on Storefront UI 2, with a 66-file refresh of its own. react-schemaorg is replaced by a new helpers/generate-json-ld.ts, and path-to-regexp moves to 8.2.0. packages/tailwind-config drops its custom screens block from both src/nextjs.ts and src/nuxt.ts.

Base metadata moves out of app/[locale]/layout.tsx into a new config/metadata.ts. The new file exports metadata and viewport, and the layout re-exports them with export { metadata, viewport } from '@/config/metadata';.

The generated Next.js app adds config/popular-searches.ts and app/[locale]/(default)/components/search-popular-searches.tsx. The generated Nuxt app adds the equivalent utils/getPopularSearches.ts and components/ui/SearchPopularSearches.vue.

In @vsf-enterprise/cms-components-utils, AgnosticCmsComponentProps gains an optional aboveFold flag. It tells a component that it renders above the fold, so the component can optimize for LCP and FCP.

AgnosticCmsHeroProps and AgnosticCmsBannerProps both gain variant: "dark" | "light". AgnosticCmsBannerProps also gains a layout prop with seven values, such as horizontal-leading-content, image-overlay, and responsive-trailing-content. The grid style field group gains grid_auto_columns and grid_auto_rows.

apps/playwright/playwright.config.ts raises the per-test timeout from 10 to 20 seconds.

The CMS hero from 1.3.0's Storefront UI 3 rebuild sent every device below the (min-width: 1024px) breakpoint the same 384px-wide background image, whatever its pixel density. On high-density phones, the hero looked soft.

BackgroundImage in apps/storefront-unified-nextjs/components/cms/page/hero.tsx used to drop srcSet from the getImageProps result for the mobile image, with props: { srcSet: _mobileSrcSet, ...mobileImgProps }. It now spreads the whole result.

matchesSnapshot and notMatchesSnapshot in apps/playwright/setup/core/base.page.ts now pass a message to expect. A snapshot mismatch reports the formatted content and the snapshot file name instead of a bare diff.

Moving to a new Alokai version meant editing every manifest by hand and keeping the recorded version right yourself.

@alokai/cli 2.2.0 adds a version command. version reports the Alokai version your project records and can write it into your package.json files. version upgrade moves your dependencies to the next Alokai version, minor and patch only.

The Console didn't know which Alokai version a deployed store runs.

store deploy matches the root package.json version field exactly against the published compatibility matrix. It sends the matching entry to the Console with your storefront and middleware manifests, scripts stripped.

Critical and high advisories were found in dependencies that Alokai packages ship.

A dependency audit ran across the whole workspace and fixed them. In the packages you install, two dependency ranges move: multer from ^2.0.1 to ^2.0.2 in @alokai/connect, and graphql-request from ^5.0.0 to ^7.2.0 in @vsf-enterprise/bigcommerce-api. @vsf-enterprise/magento-api and @vsf-enterprise/storefront-cli are part of the same audit.

@alokai/cli commands accept a --cwd flag, for example ./node_modules/.bin/alokai-cli store build --cwd=./path/to/alokai/project. They also read an ALOKAI_CWD environment variable, such as ALOKAI_CWD=./path/to/alokai/project. When you set both, the flag wins.

When a package install fails with an authentication or not-found error against the Alokai registry, the CLI reports it with specific guidance instead of the generic installer message.

The --verbose default for store dev changes from false to true, so ./node_modules/.bin/alokai-cli store dev is verbose without the flag. No flag turns it back off. The reference project's own dev script drops the flag it no longer needs.

A single-store deployment without --framework no longer fails with The "paths[1]" argument must be of type string. Received undefined. The CLI reads the framework from that store's deployment.framework in alokai.config.json instead.

@alokai/cli fixes how it reads JSON files. It also adds the playwright version override that was missing from package.json, and the scripts property the deploy parameters omitted.

The integration template's default value changes from resti-api to rest-api.

Your Playwright integration tests could run against a stale lib/ from a previous run, or against no middleware build at all. apps/playwright doesn't declare the middleware as a dependency, so dependsOn: ["^build"] never built it.

The generated project's turbo.json rewires the Playwright tasks. The shared build task declares lib/** among its outputs alongside dist/**.

playwright#test:integration depends on storefront-middleware#build, not only on ^build. playwright#test:integration:ui depends on ^storefront-middleware#build and declares inputs: ["**"]. Both Playwright tasks pass PLAYWRIGHT_OPTIONS through.

A new commercetools project keeps @vsf-enterprise/commercetools-sdk in its Next.js and Nuxt manifests instead of having it stripped. A store preset can set ignorePaths when @vsf-enterprise/storefront-cli writes alokai.config.json. Two SAP Commerce Cloud demo store presets are new.

@vsf-enterprise/cms-mock-api refreshes its homepage and sapcc-b2b mock content.

Your apps already declare @alokai/connect, so the copy in the root package.json was a duplicate you had to bump in two places on every release.

A newly generated project declares @alokai/connect only in its apps, not in its root package.json.

A new top-level lint command runs the application lint through Turbo, then lints every store. It reports each failure by application name and exits non-zero once, at the end.

A project generated on 1.3.0 runs yarn alokai version check in postinstall and before dev starts. Its dev script no longer passes the now-redundant --verbose.

When version upgrade found mismatched dependencies, it didn't say which ones. You had to run a second command to find out.

When the compatibility check fails, version upgrade no longer stops at There is a version mismatch. Please run 'version:check' for details. It prints one warning per mismatched package, as - <dependency>: expected <target>, installed <current>. version check now also reports an available newer version in a case where it used to stay silent. The documentation link printed next to a known version is now https://docs.alokai.com/alokai-versions?versionFrom=<your version>.

The images store deploy built didn't include your patch-package patches, so your deployed apps ran the unpatched upstream code.

store deploy now copies your project root's patches/ directory into each app's deploy directory and runs npx patch-package there after the install, for both storefront-middleware and storefront-unified-nextjs. If your root devDependencies declares patch-package, it uses that version.

store build leaves a package.json in every directory it composes, and .out/*/* is one of your root workspaces. So yarn install also resolved those stale copies - installing an outdated dependency set, or failing outright.

A project generated at 1.3.2 gets a "preinstall": "node ./scripts/clean-out-dir.mjs" line in its root package.json and a new scripts/clean-out-dir.mjs. The script removes .out before every install, and postinstall recreates it empty.

The API client now sends the sap-commerce-cloud-user-id header, which the getPaymentsTypes endpoint needs for the Assisted Service Module. It also passes the Authorization header to getComponentByIdAndUser, getComponentsByIdsAndUser, getPageByIdAndUser, and getPageWithUser.

configuration.customToken receives apolloContext, so you can reach the request from it. The package exports TokenParser for reading the token out of a cookie, for example TokenParser.parseToken(req.cookies[CT_COOKIE_NAME]). configuration.customRetry can now be asynchronous.

No project generated at 1.2.3 declares @vsf-enterprise/commercetools-sdk, so you adopt the package rather than bump it. The methods that changed shape are ones you call directly.

Version 5.0.0 is built on middlewareModule from @alokai/connect and ships its own ctModule. ctModule replaces the buildModule(middlewareModule<CommerceEndpoints>, ...) pattern in sdk/modules/commerce.ts.

Several methods now take positional arguments or a split identifier object instead of one flat object. Among them are customerCreatePasswordResetToken, removeProductFromCart, createMyOrderFromCart, and customerChangePassword.

@vsf-enterprise/commercetools-api 7.1.0 accepts two new optional configuration keys, apolloAgentKeepAliveOptions and apolloFetchOptions. apolloAgentKeepAliveOptions goes to the agentkeepalive HTTPS agent the Apollo HTTP link is built on. You can use it to raise timeout and freeSocketTimeout past the agent's defaults when commercetools takes longer to answer than the socket waits. apolloFetchOptions is merged into the link's own fetchOptions.

The identifier fields are no longer on a single shared interface, so reading one off the result without narrowing first stops compiling.

The generic RoutableInterface is replaced by a Route union of ProductRoute, CategoryTreeRoute, CategoryInterfaceRoute, and CmsPageRoute, exported from @vsf-enterprise/magento-types. __typename discriminates the members, and each carries its own identifier field: sku, uid, or identifier. The route function returns ApolloQueryResult<Route>.

Version 5.0.1 has no code change of its own. It moves its exact @vsf-enterprise/magento-types peer dependency from 4.0.0 to 4.0.1.

In @vsf-enterprise/magento-api 8.0.2, the built-in tokenExtension keeps the state you configured and adds its own eight cookie-backed accessors on top: getCartId, getCurrency, getCustomerToken, getStore, and their setters. In 8.0.1, it replaced state outright. Its type is also corrected.

The cart ID and its contents survive when a customer logs out. Previously, logging out cleared the cart.

A new normalizeFile normalizer handles Contentful's non-image assets. By default, it returns an object with the asset's title, fileName, and url.

The Contentful CMS module now reads a different demo space. If your project still holds the demo values the module wrote before this release, it points at a space the module no longer uses.

The Contentful CMS module's installer writes new demo values into .env.example. CNTF_SPACE changes from j8db518zbedg to 0uqx4ubljxic, and CNTF_ENVIRONMENT changes from sap-demo-b2c to master. CNTF_TOKEN is a new delivery token for that space.

MiddlewareConfig now takes both api and OAuth from the SAP Commerce Cloud middleware config, so a configuration that supplies only api no longer satisfies the type.

Version 5.0.0 requires OAuth settings in the API client configuration, in addition to api.

getPage resolves nested component references at any nesting level, with no configuration. An object that carries itemType and itemId, such as a CMSLinkComponent, is replaced by the resolved component data. CMSFlexComponent components are no longer normalized and reach the frontend as they are.

There are two new normalizers: normalizeChildren, for nested objects that aren't components, and normalizeVideo. The unified configuration gains a transformVideoUrl hook for prefixing video URLs, for example with SAPCC_MEDIA_HOST. getPage accepts searchParams for passing code and pageType.

Installing the SmartEdit CMS module now also copies a middleware api/custom-methods directory into the app and adds export { getProductReferences } from '@/api/custom-methods/getProductReferences'; to its index. It also removes the Next.js app/[locale]/(cms)/layout.tsx.

Every project generated since 1.1.0 ships a deployment workflow whose deploy step fails before it deploys anything.

The deploy step passes the workflow's verbose output as a value after a boolean flag. The CLI takes that value as a positional argument it doesn't accept. The template now renders the flag itself or nothing.