1.0

Alokai's core shipped as five separate @vue-storefront/* packages. They become one package, and only the packaging changes - the names, signatures and behaviour stay the same.

@alokai/connect and its subpaths - @alokai/connect/middleware, @alokai/connect/sdk, @alokai/connect/logger, @alokai/connect/integration-kit, @alokai/connect/config-switcher - replace @vue-storefront/middleware, @vue-storefront/sdk, @vue-storefront/logger, @vue-storefront/unified-data-model and @vue-storefront/multistore.

Ten symbols and their types are on @alokai/connect/integration-kit, not on the root: apiClientFactory, validatePassword, unifiedExtensionFactory, createUnifiedCmsExtension, getNormalizers, assignToNormalizerContext, mergeNormalizers, getApiDefinitions, defineAddCustomFieldsFactory and toContextualizedNormalizers. Every published package is rebuilt against @alokai/connect, which is why all 62 take a major version.

Multistore is the one part of the move to @alokai/connect that isn't a rename. Its configuration object changes shape, so a project that only repoints the import doesn't compile.

@vue-storefront/multistore is now @alokai/connect/config-switcher, and createMultistoreExtension is now createConfigSwitcherExtension. Each store's settings nest one level deeper, under an api key. switchStrategy: "domain" reproduces the old behaviour, mergeConfigurations has no replacement and needs none, and cacheTTL, in seconds, replaces cacheManagerFactory.

In @alokai/connect, the middleware's absolute cap on uploaded file size doubles from 10MB to 20MB.

The locale traveled in a cookie, and a CDN isn't handed cookies, so you couldn't cache responses that depended on the locale. Carrying it in a header makes them cacheable.

Every SDK request carries an x-alokai-locale header. The middleware turns it back into a vsf-locale cookie, so integrations that read the cookie keep working. getSdk in @vue-storefront/next gains a getLocale option, which makes your own apps/storefront-unified-nextjs/sdk/index.ts wrapper async.

A project that doesn't use @alokai/connect gets the same conversion by registering createCookiesBridgeExtension([{ header: 'x-alokai-locale', cookie: 'vsf-locale' }]) from @alokai/cookies-bridge as the first entry in each integration's extensions list.

The middleware writes the locale cookie itself now. A Nuxt app that keeps writing it sets a value the middleware overwrites on every request, and keeps a cookie on the responses the header change makes cacheable.

Nuxt stops writing the locale cookie and drops cookieNames.locale.

@vsf-enterprise/cms-mock-api has a new injectEnvironment endpoint. It overwrites the predefined cms-mock configuration.

createAlokaiMiddleware in @vue-storefront/next wraps your own Next.js middleware and registers the Alokai-specific logic. It appends x-pathname and x-search to the Next.js request object.

@vue-storefront/nuxt has a new server middleware handler that appends the same two headers to the Nuxt request object.

One entry of this release announces getPathnameFromRequestHeaders as added to @vue-storefront/next, and another announces it as removed. The shipped 6.0.0 doesn't export the function.

With defineSdkModule, each SDK module can live in its own file, instead of inline in the SDK config. The files go under sdk/modules/ in Next.js or sdk-modules/ in Nuxt, and an index.ts re-exports them. A widened defineSdkConfig accepts those re-exported modules.

@vue-storefront/next re-exports defineGetConfigSwitcherHeader from @alokai/connect/sdk, and Nuxt registers it as an auto-import. The defaultRequestConfig of middlewareModule accepts a getConfigSwitcherHeader function.

@vsf-enterprise/cms-components-utils no longer depends on lodash-es, which doesn't work on the Edge Runtime. The package has its own kebab-case helper instead.

In dev mode, the Nuxt cart page threw SyntaxError: The requested module '/node_modules/jw-paginate/lib/jw-paginate.js' does not provide an export named 'default'.

The fix is a jw-paginate entry in the dev optimizeDeps.include list of nuxt.config.ts. That file belongs to your project, so no package in the upgrade changes it.

The Nuxt server middleware in @vue-storefront/nuxt now imports defineEventHandler and getRequestURL from h3. Before, these imports were missing.

The metatag content in both storefronts uses the current company name.

packages/tailwind-config/src/nuxt.ts is a file in your project, not a package, so the version bump doesn't update it.

The whole Nuxt Tailwind preset in packages/tailwind-config/src/nuxt.ts is new. It builds on @storefront-ui/react/tailwind-config, with sfTypography as a plugin. The screen breakpoints sit under theme.extend.

The version field of a generated project held the ecosystem tag string where a version number belongs.

The CLI writes the version number alone into the root package.json of a generated project, where it used to write "version": "@alokai/ecosystem@1.0.1". The same value goes to the root manifest and to every apps/*/package.json.

Every published package checks the Node version on install, so your runtime decides whether you can take anything else in this release.

engines.node moves to 20.* || >=22.14.0 in the root manifest (from ^18) and in the published packages - @alokai/connect, @alokai/cli and @vsf-enterprise/sapcc-api among them. The release also expects @types/node at ^22.13.17 and .nvmrc / .node-version at 22.14.0.

A project that still points at the old registry host can't resolve any @alokai or @vsf-enterprise version in this release. The error looks like a missing package, not a registry change.

.npmrc maps the @vsf-enterprise: and @alokai: scopes to https://npm.alokai.cloud, replacing https://registrynpm.storefrontcloud.io.

express moves to ^4.20.0 in every package that embeds it, @vsf-enterprise/stripe-commercetools included. The update fixes the vulnerability in GHSA-qw6h-vgh9-j6wx.

axios moves to ^1.7.9 in 18 of the integration packages.

@alokai/cli is new to your project at 1.0.0. The store add, store move, store remove, store build, store dev, store start, store test, store changed, and store deploy commands all run through its alokai-cli binary. A generated project exposes the binary as a store script in its root package.json.

store deploy takes --framework, --project-name, and --cloud-region. They take precedence over the matching alokai.config.json values. You can't combine them with --all.

store deploy also checks for missing dependencies before it starts, instead of failing part-way through a deploy.

store changed takes --deployable. With it, the report lists only the changes to deployable stores.

store test takes --playwright-options (-p), for example alokai-cli store test --playwright-options="--project=nuxt-desktop --headed". A run over several stores tests them one after another, not in parallel through Turbo's pipeline. The command returns exit code 1 when it fails, and it works with --ui.

Store composition looks for .env and .env.example in ancestor stores before it falls back to the base apps. It creates .env from an overridden .env.example in every app. It also symlinks node_modules into each app under stores/.

On Windows, adopting the CLI needs cross-env in the project - yarn add cross-env -W -D. alokai.config.json carries deployment.framework instead of deployment.frontend. Its $schema points at node_modules/@alokai/cli/lib/static/alokaiConfigSchema.json instead of a copy checked into the repository.

A scaffolding pipeline that passes the old flag name to create breaks the next time it runs.

create builds a project from the published release bundle, not from a repository checkout. Its --inheritance-only flag is renamed to --template. The new consoleProjectName and cloudRegion flags write the Console project name and cloud region into alokai.config.json.

add-module installs modules at that release's version. It takes --store-id to name the store to install into.

Schemas written against 2.1.1 use symbols that no longer exist, so they fail to compile rather than behave differently.

The module installation context no longer has appsDirectory - a store object replaces it. addSdkMiddlewareModule replaces modifySdkConfig. createRemoveSdkPropertyVisitor is removed.

createAddMiddlewareModuleVisitor emits export const x = defineSdkModule(...). It passes a headers variable instead of the output of getRequestHeaders(). modifyFile is optional on defineSchema.

baseCmsSchemas also patches the PLP and PDP imports, adds the unifiedCms SDK module, and fixes the Nuxt Accordion import.

pushExport handles export const declarations and overwrites an existing export of the same name. With type: "javascript", modifyFile creates the inputPath when it's missing.

The CLI detects @alokai/connect in a project instead of the legacy middleware package. create now restores .gitignore and .npmrc in the project it generates. npm pack leaves both out of the published bundle, so they ship with a .template suffix that create strips.

store changed on a repository with a single commit is fixed, and so is the deployment of nested stores. The spinner no longer hides --verbose logs for start and build. A generated start:standalone script no longer ignores an existing start script.

In dev mode, middleware and SSR URLs keep a path suffix such as /api. The extensions on the CLI bin scripts are fixed. The missing defu, get-port-please, and tiny-exec dependencies are added.

The CLI reads CONSOLE_API_URL from the environment. deploy prints more debug output when it fails.

On 1.0.0, installing a CMS or search module pinned release-candidate builds of its vendor packages in your app manifests. That's vendor code that was never meant to reach production.

Installing one of eight modules now pins the stable releases of its vendor packages. The eight are Amplience, Bloomreach Content, Builder.io, Contentful, Contentstack, SAP SmartEdit, Storyblok, and Coveo. The pins move like this: @vsf-enterprise/contentful-api and @vsf-enterprise/contentful-sdk 6.0.0-rc.3 -> 6.0.0, @vsf-enterprise/amplience-api 6.0.0-rc.3 -> 6.0.0 with @vsf-enterprise/amplience-sdk 4.0.0-rc.3 -> 4.0.0, @vsf-enterprise/bloomreach-content-manager 2.0.0-rc.3 -> 2.0.0 with @vsf-enterprise/bloomreach-content-sdk 5.0.0-rc.3 -> 5.0.0, @vsf-enterprise/builderio-sdk 4.0.0-rc.3 -> 4.0.0, @vsf-enterprise/contentstack-api 6.0.0-rc.3 -> 6.0.0 with @vsf-enterprise/contentstack-sdk 5.0.0-rc.3 -> 5.0.0, @vsf-enterprise/smartedit-api 3.0.0-rc.3 -> 3.0.0 with @vsf-enterprise/smartedit-sdk 2.0.0-rc.3 -> 2.0.0, @vsf-enterprise/storyblok-api 3.0.0-rc.3 -> 3.0.0 with @vsf-enterprise/storyblok-sdk 2.0.0-rc.2 -> 2.0.0, and @vsf-enterprise/coveo-api 3.0.0-rc.3 -> 3.0.0.

Every generated project got a commercetools types package, whatever its platform. A -types package is how tooling and the next person to open your repository tell which platform a project integrates, so on any other platform it sent a false signal.

Project generation no longer writes @vsf-enterprise/commercetools-types into apps/storefront-middleware/package.json for platforms other than commercetools.

createAddIntegrationConfigPropertiesVisitor in @vsf-enterprise/module-kit adds properties to the configuration object in an integration's integrations/<integration>/config.ts. For example, createAddIntegrationConfigPropertiesVisitor('api: { uri: process.env.API_URI }') adds that api entry.

A newly generated project's root package.json has a lint:store:fix script, node scripts/lint-stores.mjs, and the @colors/colors devDependency it needs. scripts/lint-stores.mjs finds the folders to lint by reading apps/ instead of a hardcoded list. So it also covers any app your project added.

On a project whose apps/ held only the middleware, any command that read alokai.config.json failed, not just deployment.

The CLI no longer throws Default framework not found when apps/ holds neither storefront-unified-nextjs nor storefront-unified-nuxt. It leaves deployment.framework empty in the resolved store config instead.

@alokai/boilerplate-integration was private: true until this release and was never on the registry. So 1.0.1 is its first published version, not an upgrade from an earlier one. Its engines.node is >=16.x, not the workspace floor.

A SAPCC module you built yourself from middlewareModule and SapccEndpoints didn't refresh an expired token and had no image utility.

sapccModule in @vsf-enterprise/sapcc-sdk is built on middlewareModule and SapccEndpoints. It refreshes an expired token on its own and ships a transformImageUrl utility. addCartEntry and updateCartEntry are renamed to addToCart and updateCart.

@vsf-enterprise/sapcc-api applies a methodsTokenModes map such as { getProduct: TokenModes.APPLICATION }. Before this release, it ignored the map and every request used the same token.

A sap-asm install performed before this release left the assisted service endpoints with no URI to call.

Installing the sap-asm module writes asmUri: process.env.SAPCC_ASM_API_URI into configuration.api in apps/storefront-middleware/integrations/sapcc/config.ts. It also appends SAPCC_ASM_API_URI to apps/storefront-middleware/.env.example.

@vsf-enterprise/unified-api-commercetools/algolia normalizes deeply nested categories correctly.

The unified setCartAddress dropped the region before it reached Magento, so Magento never checked what your storefront put in region.

The unified setCartAddress in @vsf-enterprise/unified-api-magento resolves region and region_id from the shippingAddress argument. It passes both on to the Magento API.

@vsf-enterprise/unified-api-sfcc picks up updated @vsf-enterprise/sfcc-api and @vsf-enterprise/sfcc-types dependencies.

The generated project's .github/workflows/continuous-integration.yml no longer declares a node-version: ["18.20.2"] matrix. Nothing read that matrix: the setup action installs Node from .nvmrc through actions/setup-node. runs-on moves from ubuntu-latest-8core to ubuntu-latest, the runner every GitHub plan provides, instead of a larger-runner tier.

The generated project's .github/actions/affected-stores/action.yml calls store changed with --deployable. A store without frontend components no longer blocks the run. The --deployable flag itself isn't new in this release.