1.2
CMS modules get their own SDK namespaces, integration boilerplates arrive, and Magento's SDK becomes a proxy module
Showing every integration. Set your stack in Preferences and this page hides what isn't yours.
20.* || >=22.14.0Two changes in this line cost you real work, and both land in files your project owns. First, every CMS Storefront Module now registers its own Unified SDK namespace instead of the single shared sdk.unifiedCms, and moves its code into @/sf-modules/<module_name>/. That's what lets you run more than one CMS, and it's also why the module installer's clean-up step no longer matches a project still laid out the 1.1.0 way. Second, @vsf-enterprise/magento-sdk@6.0.0 deletes every hand-written method and its client export, and becomes a thin middlewareModule proxy.
The patches add framing protection to newly generated Next.js projects. 1.2.2 puts X-Frame-Options: DENY in next.config.mjs, and 1.2.3 moves it into the middleware so the documented opt-out works on a deployed build. Neither patch reaches your own copy of those files. Everything else is smaller: new integration and extension boilerplates behind a --template flag (1.2.0 shipped it with a broken default and 1.2.1 corrects it), generated Nuxt auto-imports, and a Contentstack live-preview fix that needs one argument added to your own getPage call.
Highlights
Each CMS module now owns its SDK namespace, so you can run more than one CMS
@vsf-enterprise/module-kitThe single shared sdk.unifiedCms namespace and UnifiedCmsEndpoints type left room for one CMS module only, so you couldn't run a second one at all.
CMS modules no longer share the sdk.unifiedCms namespace and the UnifiedCmsEndpoints type. Each module registers its own namespace - sdk.unifiedAmplience, sdk.unifiedBloomreachContent, sdk.unifiedBuilderio, sdk.unifiedContentful, sdk.unifiedContentstack, sdk.unifiedCmsMock, sdk.unifiedSmartedit, sdk.unifiedStoryblok - with its own Unified<ModuleName>Endpoints type and its own SDK module file (unified-contentful.ts, unified-cms-mock.ts, and so on).
The module's app code moves under @/sf-modules/<module_name>/. Its dynamic-page interfaces move to @/sf-modules/<module_name>/types/index.ts, and @/types/cms.ts re-exports them. @/components/cms/wrappers/index.ts re-exports the module's wrappers.
In Nuxt, the useCmsPage composable is deprecated in favour of a ConnectCmsPage wrapper component. @vsf-enterprise/module-kit@4.0.0 rewrites the shared install schema to match this layout.
Nothing breaks on the version bump alone. These are files in your project, so your existing sdk.unifiedCms setup keeps working untouched.
It breaks when you install or reinstall a CMS module. The shared clean-up step looks for the exact 1.2.0 names (@/sf-modules/cms-mock/types, 'cms-mock': cmsMockConfig, @/sdk/modules/unified-cms-mock). On a project still holding the 1.1.0 names (@/integrations/cms-mock/types, cms: cmsConfig, @/sdk/modules/unified-cms), it silently removes nothing and leaves the CMS Mock wiring behind. Restructure first if you plan to run a second CMS module, or to add one at all.
Integration and extension boilerplates, and integration generate now needs --template
@alokai/cli@vsf-enterprise/file-modifierEvery integration started from the same generic skeleton, whatever kind of integration you were writing.
alokai-cli integration generate in @alokai/cli@2.1.0 builds from named boilerplate templates - openapi, graphql, rest-api, sdk-proxy - that you pick with the new --template flag. It no longer passes arguments to the plop generator through environment variables.
The new alokai-cli extension generate --template=<unified-commerce|unified-cms> --target-integration=<integration> command generates an extension for an existing integration. It builds from the @alokai/boilerplate-integration-extension package, which this release publishes for the first time. @vsf-enterprise/file-modifier@3.2.0 adds the createAddToFunctionFirstObjectArgumentVisitor visitor those generators build on.
If you generate custom integrations, you can now start from a template that fits the kind of integration instead of one generic skeleton. sdk-proxy lets you expose an external SDK's methods through the middleware.
But --template defaults to resti-api, which isn't one of the four template names. So alokai-cli integration generate <name> without --template installs the boilerplate and then exits 1 with Template 'resti-api' not found. Any scripted or habitual invocation has to pass the flag, and any environment variables a wrapper script set for the generator now set nothing.
Nuxt auto-imports are generated for you
@alokai/cliNuxt's auto-import declarations are generated files, so whether they matched your code depended on whatever last ran nuxt prepare.
@alokai/cli@2.1.0 runs nuxt prepare for each Nuxt store when store dev syncs the store and when the store is composed. The generated Nuxt app now relies on these auto-imports for its own composables. useCartMutation, useSeoProduct and their neighbours are no longer imported by hand in composables/useCart/* or components/ui/PurchaseCard/PurchaseCard.vue.
Auto-imported composables and components resolve in your editor and in typecheck without a manual nuxt prepare. store dev's watch mode now tells you when a sync has finished, so you know when the generated types are current. Your own explicit imports keep working - dropping them is optional cleanup, not a required edit.
All changes by area
Every change in 1.2 has one entry here, grouped by area. The highlights, from above and from the patch sections, are here too, marked with a star. Open an area to see its changes, and open a change to read why it changed and what changed. The upgrade guide from 1.1.0 to 1.2.3 collects the migration steps for the whole line.
StorefrontAction needed8 changes
changed Each CMS module now owns its SDK namespace, so you can run more than one CMS highlight Action needed
Nothing breaks on the version bump - these are your own files. It breaks when you install or reinstall a CMS module: the clean-up step looks for the exact 1.2.0 names, so on a project still on the 1.1.0 names it silently leaves the old CMS wiring behind.
step →What changedWhy, and what changed ▸
The single shared sdk.unifiedCms namespace and UnifiedCmsEndpoints type left room for one CMS module only, so you couldn't run a second one at all.
Each CMS module registers its own SDK namespace - sdk.unifiedAmplience, sdk.unifiedBloomreachContent, sdk.unifiedBuilderio, sdk.unifiedContentful, sdk.unifiedContentstack, sdk.unifiedCmsMock, sdk.unifiedSmartedit, sdk.unifiedStoryblok - with its own Unified<ModuleName>Endpoints type and SDK module file. The module's app code moves under @/sf-modules/<module_name>/, and its dynamic-page interfaces move to @/sf-modules/<module_name>/types/index.ts. @/types/cms.ts re-exports the interfaces, and @/components/cms/wrappers/index.ts re-exports the wrappers.
In Nuxt, useCmsPage is deprecated in favour of a ConnectCmsPage component. @vsf-enterprise/module-kit@4.0.0 rewrites the shared install schema to match.
@vsf-enterprise/module-kitchanged Nuxt auto-imports are generated for you highlight
Auto-imported composables and components resolve in your editor and in typecheck without a manual nuxt prepare. Your own explicit imports keep working - dropping them is optional cleanup.
What changedWhy, and what changed ▸
Nuxt's auto-import declarations are generated files, so whether they matched your code depended on whatever last ran nuxt prepare.
@alokai/cli@2.1.0 runs nuxt prepare for each Nuxt store when store dev syncs the store and when the store is composed. The generated Nuxt app now relies on these auto-imports for its own composables and no longer imports them by hand.
@alokai/clichanged The Playwright app manifest moves its test runner and lint config pins
The Playwright manifest is part of your project, so the upgrade doesn't move its pins. They move only when you change them.
What changedWhy, and what changed ▸
In apps/playwright/package.json, @playwright/test moves from 1.45.0 to 1.54.1. @vue-storefront/eslint-config moves to 5.1.1.
changed The middleware lint scripts skip generated integration code
The middleware lint scripts are part of your project. Lint keeps failing on a generated integration until you add the same flag to your scripts.
What changedWhy, and what changed ▸
The lint and lint:fix scripts in apps/storefront-middleware/package.json run eslint --ignore-pattern='**/generated/**', so generated integration code no longer fails lint. The new integration boilerplates put that code in the generated/ directories the flag excludes.
changed The accessibility fixture launches Chrome without the sandbox
The accessibility fixture is a file in your project, so an accessibility run inside a container keeps failing until you make the same edit.
What changedWhy, and what changed ▸
The expectA11yCompliance fixture in apps/playwright/setup/fixtures/a11y.ts launches pa11y's Chrome with chromeLaunchConfig.args set to ['--no-sandbox', '--disable-setuid-sandbox']. With these arguments, the accessibility suite runs inside a container.
added New projects refuse to be embedded in an iframe - your existing project still allows it highlight Action needed 1.2.2
Your storefront can still be framed by any origin after this upgrade. Adding the header is a hand edit to your own next.config.mjs. Before you apply it, check whether you use CMS live preview: the CMS modules render the storefront inside an iframe, and DENY blocks that. If you do, set NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER to true.
What changedWhy, and what changed ▸
A storefront that serves no X-Frame-Options header can be embedded in an iframe by any origin, and this release's position is that it shouldn't be.
apps/storefront-unified-nextjs/next.config.mjs gains a headers entry that serves X-Frame-Options: DENY on every route. It's wrapped in env('NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER') !== 'true', so the header can be switched off. That default applies to a project generated at 1.2.2 and not to yours.
changed The mock CMS homepage content was reworked Action needed 1.2.2
This is demo content only. If you serve your own CMS, you won't see the change. If you use the mock, your homepage renders different categories and banners after the upgrade, so anything that asserts the old content no longer matches it.
What changedWhy, and what changed ▸
The mock CMS serves the reference storefront's homepage, so changing its content changes what every mock-backed project renders.
@vsf-enterprise/cms-mock-api serves reworked homepage content in every platform's content set. It adds a new cap-game-strong hero and a homeBannersHeading editorial component. In categoryCard, woman becomes biking, clothes becomes running, and man is removed. The homeCategoriesGrid and homeBannersGrid entries are reshuffled.
@vsf-enterprise/cms-mock-apifixed The X-Frame-Options opt-out now takes effect at request time instead of at build time highlight Action needed 1.2.3
If you run CMS live preview, the opt-out now works without rebuilding the app. Neither file is touched by upgrading, so the move reaches only projects generated at 1.2.3 or later unless you apply it yourself. The header is now sent on page responses only, no longer on API routes, _next assets, /images, /icons, or any path containing a dot.
What changedWhy, and what changed ▸
The opt-out for the X-Frame-Options header was decided when next build ran. Setting NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER=true on an already-built deployment did nothing, so the iframe stayed blocked and CMS live preview kept failing.
In 1.2.2, apps/storefront-unified-nextjs/next.config.mjs set the X-Frame-Options: DENY header, gated behind env('NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER') !== 'true' and evaluated at build time. 1.2.3 deletes that block and sets the same header from apps/storefront-unified-nextjs/middleware.ts, where env(...) is read per request.
CLI & toolingAction needed11 changes
changed Integration and extension boilerplates, and integration generate now needs --template highlight Action needed
alokai-cli integration generate defaults --template to resti-api, which isn't one of the four template names, so without the flag it installs the boilerplate and exits 1 with Template 'resti-api' not found. Any scripted or habitual invocation has to pass the flag, and any environment variables a wrapper script set for the generator now set nothing.
What changedWhy, and what changed ▸
Every integration started from the same generic skeleton, whatever kind of integration you were writing.
integration generate in @alokai/cli@2.1.0 builds from named templates - openapi, graphql, rest-api, sdk-proxy - that you pick with a new --template flag. The new extension generate --template=<unified-commerce|unified-cms> --target-integration=<integration> command builds from the new @alokai/boilerplate-integration-extension package. @vsf-enterprise/file-modifier@3.2.0 adds the createAddToFunctionFirstObjectArgumentVisitor visitor those generators build on.
@alokai/cli@vsf-enterprise/file-modifieradded The AI context files the CLI writes are framework- and integration-specific
Only projects generated after this release get the new layout. An existing project has no ai/ directory, and its three merged AI rules files still carry the rules for every framework and every integration.
What changedWhy, and what changed ▸
A new ai/ directory ships in the project: ai/general-rules.md, ai/frontend/<nextjs|nuxt>/index.md, ai/integrations/<integration>/index.md, and ai/README.md. @vsf-enterprise/storefront-cli@3.1.0 merges only the general rules, your framework's rules, and your integration's rules into .cursorrules, .windsurfrules, and .github/copilot-instructions.md.
@vsf-enterprise/storefront-clifixed add-module no longer skips a module's install schema
A module whose source has no framework directory now installs its schema, instead of silently installing nothing.
What changedWhy, and what changed ▸
In @vsf-enterprise/storefront-cli@3.1.0, storefront-cli add-module no longer skips a Storefront Module's install schemas when the module source has no framework-specific directory.
@vsf-enterprise/storefront-cliadded create and add-module take a registry-url flag
You don't have to do anything. The flag points create and add-module at a registry other than the default.
What changedWhy, and what changed ▸
@vsf-enterprise/storefront-cli@3.1.0 adds a registry-url flag to its create and add-module commands. The flag is for development purposes.
@vsf-enterprise/storefront-clichanged module-kit gains a skip property, a new visitor and a shared CMS clean-up schema
No project manifest lists module-kit, because the CLI resolves it when a module command runs. These changes reach you the next time you install a module, not when you bump versions.
What changedWhy, and what changed ▸
@vsf-enterprise/module-kit@4.0.0 adds a skip property that skips a schema operation at runtime. It also adds an addUnifiedExtensionObjectProperties visitor and a shared clean-up schema in base-cms.
The release fixes three bugs. The clean-up schema no longer blocks the operations after it. Asset installation in modules for Nuxt is fixed, and so is merging objects that contain a satisfies clause.
@vsf-enterprise/module-kitfixed file-modifier fixes deep object merges
The merge fixes reach you when you install a module, not through a dependency you declare.
What changedWhy, and what changed ▸
@vsf-enterprise/file-modifier@3.2.0 fixes merging several properties at once through mergeIntoObjectDeep. It also fixes merging objects that contain a satisfies clause.
@vsf-enterprise/file-modifierfixed The shared lint config clears a prettier plugin crash
If your lint crashes with TypeError: Cannot read properties of undefined (reading 'message'), moving the lint config to 5.1.1 fixes it.
What changedWhy, and what changed ▸
@vue-storefront/eslint-config@5.1.1 bumps eslint-plugin-prettier to 5.5.3. That version fixes a TypeError: Cannot read properties of undefined (reading 'message') crash during lint.
@vue-storefront/eslint-configfixed store prepare lints its generated files correctly
The fix comes with the CLI version, so you have nothing to apply.
What changedWhy, and what changed ▸
@alokai/cli@2.1.0 fixes linting of the files that alokai-cli store prepare generates.
@alokai/clichanged The GraphQL integration boilerplate was refreshed
You get the refreshed template the next time you generate an integration. Nothing changes in an integration you already generated.
What changedWhy, and what changed ▸
@alokai/boilerplate-integration@1.2.0 refreshes the GraphQL boilerplate and aligns its AI prompts with the other boilerplates. It ships a README written for the integration template, instead of a generic one.
@alokai/boilerplate-integrationfixed Generating a custom integration works without naming a template highlight 1.2.1
On 1.2.0, integration generate installed the boilerplate into a temporary directory and then exited with Template 'resti-api' not found. It wrote nothing into your project, so there's nothing to clean up. If you worked around it by passing --template rest-api, you can drop the flag.
What changedWhy, and what changed ▸
integration generate failed unless you passed --template yourself, because its default template name was misspelled.
The template flag on integration generate defaulted to resti-api, which isn't one of its templates (openapi, graphql, rest-api, sdk-proxy). The default is now rest-api.
@alokai/clifixed extension generate --template=unified-commerce now works highlight Action needed 1.2.2
The fix doesn't arrive with a package bump. extension generate installs the boilerplate at whatever version your project's root package.json reports as its own "version", so a project still marked 1.2.1 keeps fetching the broken boilerplate and keeps failing. Set that "version" to the release you're on, or pass --version=1.2.2 on each run.
What changedWhy, and what changed ▸
extension generate --template=unified-commerce failed on every run since it shipped in 1.2.0, because its generator pointed at a template directory that doesn't exist.
The unified-commerce generator in @alokai/boilerplate-integration-extension pointed at templates/unified, which doesn't exist. It now points at templates/unified-commerce, where the templates live. --template=unified-cms was never affected.
@alokai/boilerplate-integration-extensioncommercetools1 change
added getCartVersion lets you resolve the cart id and version yourself
If you don't set getCartVersion, the default behavior is unchanged: the extension fetches the active cart for the current user.
What changedWhy, and what changed ▸
@vsf-enterprise/unified-api-commercetools@4.1.0 adds a getCartVersion option to the unified config of createUnifiedExtension. It lets you resolve the cart id and version your own way - for multiple carts, cart switching by user context, or an external cart manager. The option's JSDoc carries its signature.
@vsf-enterprise/unified-api-commercetoolsMagento 2Action needed4 changes
changed The Magento SDK is now a proxy module Action needed
If your storefront imports magentoModule, client, or a method type, tsc fails after the version bump. client and the method types have no replacement under the same names, and every buildModule call that uses magentoModule needs the new call shape.
What changedWhy, and what changed ▸
The SDK carried hand-written methods and a client export for endpoints that middlewareModule already reaches by proxying the middleware directly.
@vsf-enterprise/magento-sdk@6.0.0 is now a Proxy SDK module built on middlewareModule from @alokai/connect/sdk. Every hand-written method is gone, and so are the client export, the connector, and the method types the SDK used to re-export.
magentoModule is now a generic you call, not a factory you pass to buildModule: buildModule(magentoModule<MagentoEndpoints>({ apiUrl })). The peer range on @alokai/connect moves to ^1.1.0, which 1.1.0 already satisfies.
@vsf-enterprise/magento-sdkchanged The raw placeOrder response moves the order under orderV2 Action needed
If your code reads response.data.placeOrder.order, change it to read response.data.placeOrder.orderV2.
What changedWhy, and what changed ▸
The detailed order information in the raw placeOrder response moved to a new field, so code reading the old field no longer finds it.
The raw placeOrder GraphQL response in @vsf-enterprise/magento-api@8.0.0 returns detailed order information in the orderV2 field instead of order.
@vsf-enterprise/magento-apiadded placeOrder is a unified API method for Magento
Nothing to change. Calling the unified placeOrder instead of the raw one keeps your code clear of the orderV2 change.
What changedWhy, and what changed ▸
@vsf-enterprise/unified-api-magento@5.0.0 makes placeOrder a unified API method for Magento. It returns a normalized order, like every other unified method, and reads the new orderV2 field itself.
@vsf-enterprise/unified-api-magentochanged The Magento GraphQL schema moves to 2.4.8 Action needed
Run typecheck over any code that touches raw Magento types, even if you never used magentoModule. A field that moved or changed shape in the schema shows up there and nowhere else.
What changedWhy, and what changed ▸
The generated Magento types mirror the GraphQL schema, and the packages now target Magento 2.4.8 instead of 2.4.6.
The Magento GraphQL schema behind @vsf-enterprise/magento-types@4.0.0 moves from 2.4.6 to 2.4.8. The new schema can add types and fields or change existing ones. @vsf-enterprise/unified-api-magento@5.0.0 is aligned with 2.4.8 too.
@vsf-enterprise/magento-types@vsf-enterprise/unified-api-magentoBigCommerce1 change
deprecated The BigCommerce schema gains optional fields and several deprecations
Nothing was removed, so nothing breaks now. GraphQLResponse, GraphQLError, and GraphQLData are slated for removal in the next major, so move any code that names them before then. Customer.addressCount and Customer.notes carry no removal date, but Customer.notes returns an empty string, because the Storefront GraphQL API doesn't support notes - read the metafield instead.
What changedWhy, and what changed ▸
The BigCommerce GraphQL schema behind @vsf-enterprise/bigcommerce-api@8.1.0 and @vsf-enterprise/bigcommerce-types@3.1.0 is updated with no breaking changes. Some properties gain optional fields.
Customer.addressCount is deprecated - use Customer.addresses.collectionInfo.totalItems instead. Customer.notes is deprecated - use Customer.metafields.edges.find(edge => edge.node.key === 'notes')?.node.value instead. The GraphQLResponse, GraphQLError, and GraphQLData types are deprecated too.
@vsf-enterprise/bigcommerce-api@vsf-enterprise/bigcommerce-typesSalesforce Commerce Cloud1 change
changed unified-api-sfcc re-pins its SFCC api and types
Your generated middleware manifest declares @vsf-enterprise/sfcc-api directly, so the versions table gives it a row of its own instead of folding it into unified-api-sfcc.
What changedWhy, and what changed ▸
@vsf-enterprise/unified-api-sfcc@4.0.1 re-pins @vsf-enterprise/sfcc-api to 3.1.0 and @vsf-enterprise/sfcc-types to 1.6.0. There's no API change.
@vsf-enterprise/unified-api-sfccContentfulAction needed1 change
changed Installing the Contentful module stops writing CNTF_PREVIEW_TOKEN Action needed 1.2.2
An existing install keeps whatever your .env already holds. An install or re-install from this release on leaves out the preview token, so add CNTF_PREVIEW_TOKEN to apps/storefront-middleware/.env yourself. If you're on a platform other than SAP Commerce Cloud and took the demo values as written, set CNTF_ENVIRONMENT to your own.
What changedWhy, and what changed ▸
The module's own config still reads CNTF_PREVIEW_TOKEN, so an example file without it leaves live preview unconfigured, with nothing pointing at why.
Installing the Contentful CMS module writes different demo values into apps/storefront-middleware/.env.example. CNTF_TOKEN and CNTF_SPACE point at a new demo space. CNTF_ENVIRONMENT is a fixed sap-demo-b2c instead of being derived from your commerce platform. The CNTF_PREVIEW_TOKEN line isn't written at all, while the module's own middleware/config.ts still reads CNTF_PREVIEW_TOKEN and passes it as previewToken.
ContentstackAction needed1 change
fixed Contentstack live preview reads its query from searchParams instead of a cookie Action needed
If you use live preview, pass the page's searchParams to your own getPage call. Without it nothing crashes - the missing argument is caught and logged as a warning, not thrown - but live preview stops resolving content.
What changedWhy, and what changed ▸
After a live preview, CMS pages returned random 404s, because the preview query travelled in a cookie.
getPage in @vsf-enterprise/contentstack-api@6.0.1 reads the live-preview query from a new optional searchParams argument instead of the vsf-live-preview-query cookie. @vsf-enterprise/contentstack-sdk@5.0.1 stores the query in the URL's search params.
@vsf-enterprise/contentstack-api@vsf-enterprise/contentstack-sdkAmplience1 change
changed Installing the Amplience module points at a new demo hub 1.2.2
An existing install keeps its current values. Only a fresh install picks up the new ones.
What changedWhy, and what changed ▸
Installing the Amplience CMS module writes a different demo hub into apps/storefront-middleware/.env.example: AMPL_HUB_NAME and AMPL_STAGING_ENV both point at a new Alokai demo hub.
Patches in 1.2.x
1.2.3
24 Sept 2025 · Patch · 2 of 71 packages moved
One change, and it lands in files your project owns, so bumping the packages changes nothing you can see. It moves the X-Frame-Options header from apps/storefront-unified-nextjs/next.config.mjs, where 1.2.2 set it, into the Next.js middleware, so the NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER=true opt-out works on a deployed build. The packages that moved are boilerplates the CLI fetches on demand, so you don't edit a version in any manifest.
The X-Frame-Options opt-out now takes effect at request time instead of at build time
The opt-out for the X-Frame-Options header was decided when next build ran. Setting NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER=true on an already-built deployment did nothing, so the iframe stayed blocked and CMS live preview kept failing.
In 1.2.2, apps/storefront-unified-nextjs/next.config.mjs set the X-Frame-Options: DENY header through headers: async () => [...] on source: '/(.*)', gated behind env('NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER') !== 'true'. next build resolves headers() once and writes the result into .next/routes-manifest.json, so that gate was evaluated at build time. 1.2.3 deletes the block from next.config.mjs and sets the same header from apps/storefront-unified-nextjs/middleware.ts, where env(...) is read per request.
If you run CMS live preview (Contentful, Amplience), the opt-out the live-preview documentation tells you to set now works without rebuilding the app. On 1.2.2, NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER=true injected at deploy time into an already-built standalone image had no effect, and you had to rebuild with the variable set.
Neither file is touched by upgrading, so the move reaches only projects generated at 1.2.3 or later unless you apply it to your own copy. It also narrows where the header goes. The middleware's matcher is ['/((?!api|_next|images|icons|.*\\..*).*)'] in both 1.2.2 and 1.2.3, so the header is now sent on page responses only, and no longer on API routes, _next assets, /images, /icons, or any path containing a dot. next.config.mjs matched /(.*), which was every response.
1.2.2
11 Sept 2025 · Patch · 3 of 71 packages moved
A new X-Frame-Options: DENY response header ships in the Next.js config, but only for projects generated from this release on. The upgrade doesn't touch your own next.config.mjs, so you add the header by hand, and it breaks CMS live preview until you set the opt-out variable. extension generate --template=unified-commerce failed outright and now works, but only once the CLI fetches the fixed boilerplate, which it picks by your project's own version marker, not by any package you bump. Everything else is demo content and demo credentials, and one of those, the Contentful module's .env.example, drops a variable the module still reads.
1.2.1 was released from a different branch, but its only change - the integration generate default template corrected from resti-api to rest-api - is in 1.2.2 too, so nothing shipped in 1.2.1 is missing from this release.
New projects refuse to be embedded in an iframe - your existing project still allows it
A storefront that serves no X-Frame-Options header can be embedded in an iframe by any origin, and this release's position is that it shouldn't be.
apps/storefront-unified-nextjs/next.config.mjs gains a headers entry that serves X-Frame-Options: DENY on every route. It's wrapped in env('NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER') !== 'true', so the header can be switched off. That default applies to a project generated at 1.2.2 and not to yours: next.config.mjs belongs to your project, not to the upgrade, so bumping packages doesn't change how your site can be framed.
Your storefront can still be framed by any origin after this upgrade. Adding the header is a hand edit to your own next.config.mjs. Before you apply it, check whether you use CMS live preview: Contentful, Amplience, and the other CMS modules render the storefront inside an iframe, and DENY blocks that. If you do, set the NEXT_PUBLIC_DISABLE_X_FRAME_OPTIONS_HEADER environment variable to true.
extension generate --template=unified-commerce now works
@alokai/boilerplate-integration-extensionextension generate --template=unified-commerce failed on every run since it shipped in 1.2.0, because its generator pointed at a template directory that doesn't exist.
The unified-commerce generator in @alokai/boilerplate-integration-extension pointed at templates/unified, which doesn't exist. Every run of ./node_modules/.bin/alokai-cli extension generate --template=unified-commerce therefore died on a missing path. The generator now points at templates/unified-commerce, where the templates live. --template=unified-cms was never affected, because its own generator already pointed at the right directory.
The fix doesn't arrive with a package bump. ./node_modules/.bin/alokai-cli extension generate installs the boilerplate at whatever version your project's root package.json reports as its own "version", so a project still marked 1.2.1 keeps fetching the broken boilerplate and keeps failing. Set that "version" to the release you're on, or pass --version=1.2.2 on each run.
1.2.1
21 Aug 2025 · Patch · 3 of 71 packages moved
One fix: the --template default on alokai integration generate was misspelled resti-api in 1.2.0, so the command aborted unless you passed the flag yourself. 1.2.1 corrects it to rest-api. Nothing else reaches a running project: no file the CLI writes at project creation changed, no third-party pin in a generated manifest moved, and the Node floor is where 1.2.0 left it. Of the package versions that moved, one is a hand edit to your package.json, and there's nothing to port.
Generating a custom integration works without naming a template
@alokai/cliintegration generate failed unless you passed --template yourself, because its default template name was misspelled.
The template flag on integration generate defaulted to resti-api, which isn't one of its templates (openapi, graphql, rest-api, sdk-proxy). The default is now rest-api.
On 1.2.0, yarn alokai integration generate <name> installed the boilerplate into a temporary directory and then exited with Template 'resti-api' not found. Available templates: graphql, openapi, rest-api, sdk-proxy. On a project that predates the alokai root script, the command is ./node_modules/.bin/alokai-cli integration generate <name>, and it failed the same way. It wrote nothing into your project, so there's no half-generated integration to clean up. The flag itself was never broken: if you passed --template rest-api to work around the bug, you can drop it.