Version Packages (canary)

[github-actions]

This PR was opened by the Changesets release GitHub action. When you're ready to do a release, you can merge this and the packages will be published to npm automatically. If you're not ready to do a release yet, that's fine, whenever you add more changesets to canary, this PR will be updated.

Releases

@bigcommerce/catalyst@1.4.0

Minor Changes

• #3203 b68192a Thanks @jorgemoya! - Upgrade @opennextjs/cloudflare from 1.17.3 to 1.20.6, and the Wrangler version the build runs from 4.90.0 to 4.128.0.

  A stray @opennextjs/cloudflare entry is also removed from the repo root, where it should never have been. The adapter stays a peer dependency of the CLI package, which is the correct declaration: the copy that matters has to live in the merchant's own project, both so the build can invoke the adapter's binary from there and because the generated open-next.config.ts imports it. Wrangler is not declared anywhere, since the build invokes a pinned version directly. Neither belongs in this repo's dependency graph.

  catalyst build and catalyst deploy now offer to update a project's own @opennextjs/cloudflare pin when it has fallen behind the version the CLI targets, and reinstall so the worker is compiled against it. The check runs on the shared build path, immediately before the adapter is invoked. That pin lives in the project's package.json, so it previously stayed at whatever version the project was scaffolded with and adapter fixes were skipped with no indication at all.

  The upgrade is offered only when it is safe to take. A project whose Next.js version the newer adapter does not support is told to run catalyst upgrade first, rather than being handed an unsupported dependency set. Nothing is changed under catalyst deploy --prebuilt, which skips the build and would upload a bundle the new adapter never compiled, nor in a non-interactive environment such as CI, where rewriting dependencies would break an install against a frozen lockfile — both report the exact command to run instead. A project already on, or ahead of, the target version is left alone silently.

  The adapter's version range on the CLI is relaxed to ^1.17.3 and marked optional, and a stray @opennextjs/cloudflare entry is removed from the repo root. It was previously an exact pin, which meant projects still on the older adapter version could not install the upgraded CLI at all — the projects the upgrade prompt above is meant to reach — and projects hosted somewhere that never installs the adapter reported it as missing.

  Node 20 is dropped from the supported engines range, which is now ^22.0.0 || ^24.0.0. Every Wrangler release the adapter now accepts requires Node 22 or later. In practice catalyst build and catalyst deploy already could not work on Node 20, because the previously pinned wrangler@4.90.0 also requires it; what does regress is catalyst start.

  For stores already deployed on Commerce Hosting, the sharded tag cache Durable Object adds two columns to its table the first time it is accessed after the next deploy, backing the stale-while-revalidate revalidateTag support added upstream. The migration is automatic and no configuration change is needed.

  Fixes picked up in the range include a security fix for encoded paths bypassing middleware matching or selecting partially-decoded cache entries, a fix for /_next/static/* returning 404 on past deployments when a metadata-only Worker version became the newest one, and R2 cache population over remote dev, which is not subject to the Cloudflare API rate limit of 1,200 requests per 5 minutes that failed builds for large catalogs.

• #3205 02aa913 Thanks @jorgemoya! - Add channel checkout URL support to the CLI: catalyst channels info reports it, catalyst channels update gains --checkout-url and --remove-checkout-url, and catalyst deploy gains --update-checkout-url.

  Checkout is hosted by BigCommerce and the redirect target is resolved server-side from channel config, so a storefront moved onto a Native Hosting domain keeps sending shoppers to whatever checkout domain the channel had before — with nothing in the CLI to inspect or change it.

  catalyst channels info — or bare catalyst channels, which now defaults to it — prints the channel's storefront, canonical and checkout URLs, and calls out when the channel has no checkout URL of its own (in which case BigCommerce falls back to the default channel's primary URL, which may be an unrelated domain).

  catalyst channels update gains --checkout-url alongside --hostname, so both of a channel's URLs can be set in one command; passing a checkout flag on its own changes only the checkout URL and leaves the storefront URL alone. --remove-checkout-url reverts to the shared checkout domain and then reports where checkout actually landed, since the domain it falls back to belongs to the default channel and can't be known beforehand.

  catalyst deploy --update-checkout-url, alongside the existing --update-site-url, lets a merchant setting up a custom domain configure both of a channel's URLs in one pass. It prompts for the checkout URL after a successful deploy, defaulting to the checkout. subdomain of the channel's storefront domain. Unlike the site URL this can't be derived from the deployment, since the checkout domain has to already point at BigCommerce with a certificate provisioned there. Passing both flags resolves the channel once rather than asking twice, and either flow failing leaves the deploy reported as successful, since the bundle is already live by that point.

  All three surfaces warn when a channel's checkout domain doesn't share a main domain with its storefront. Pointing a channel's site URL at a new domain silently leaves checkout on the old one, and a cross-domain checkout is where shopper sessions and carts stop carrying over in browsers that restrict cross-domain cookies. catalyst channels update and catalyst deploy --update-site-url check for this right after they move the site URL, and catalyst channels info reports it too. The advice adapts to the storefront domain: on a custom domain it suggests the checkout.<domain> subdomain to point at BigCommerce, and on an auto-generated deployment hostname it explains that the shared checkout domain is the only option there and that a custom domain is the prerequisite for changing it. Two situations warn, with different copy: a channel that has never had a checkout URL of its own is inheriting the default channel's primary URL, which is where every channel starts; a channel whose own checkout URL no longer matches its storefront has most likely been left behind by a storefront URL change. The consequence is the same either way, so both warn — only the remedy differs. The check is advisory and never fails the command that ran it. Hostnames are compared by registrable domain using the public suffix list, matching what BigCommerce itself enforces: store-x.example.store and store-x.c.example.store share a domain and are accepted, while example.co.uk and other.co.uk do not.

  When catalyst channels info finds a cross-domain checkout it offers to fix it on the spot rather than only reporting it. The channel is already selected and the site already fetched at that point, so it prompts right there — defaulting to the checkout. subdomain of the storefront domain — instead of making you re-run the work as catalyst channels update --checkout-url. The offer is withheld in the two cases where it wouldn't help: when the storefront sits on a BigCommerce-managed hosting zone, where no checkout URL can be issued a certificate and BigCommerce would reject every value, and in non-interactive runs, which print the catalyst channels update command to run instead so the command stays scriptable.

  BigCommerce requires the checkout URL to share a main domain with the channel's storefront URL, so sessions carry between the two. That rule is enforced by the API rather than pre-checked locally — determining the registrable domain correctly requires the public suffix list — so the server's own explanation is surfaced verbatim on rejection. Note this also means a custom checkout URL is only possible on a custom storefront domain, and that the checkout domain must be pointed at BigCommerce with a certificate provisioned there, not added with catalyst domains add.

Patch Changes

• #3159 49a3432 Thanks @jorgemoya! - Fix catalyst build/catalyst deploy failing on native Windows during the OpenNext step. The generated open-next.config.ts hardcoded node_modules/.bin/next build as its buildCommand, which OpenNext runs through execSync (cmd.exe on Windows) — where the extensionless POSIX shim and forward-slash path fail to resolve. It now invokes node ./node_modules/next/dist/bin/next build, which works identically across sh and cmd.exe while still skipping the project's generate step.

• #3169 ed8fc56 Thanks @jorgemoya! - Bind a CATALYST_ROUTES_KV Cloudflare KV namespace in the generated Wrangler config, so the routing cache used by proxies/with-routes has a shared store on BigCommerce Native Hosting instead of degrading to a per-invocation in-memory cache. The generated config points at a local-only placeholder namespace id used by wrangler dev/catalyst start and the wrangler deploy --dry-run bundling step; the real per-project namespace is bound at deploy time.

• #3213 cdee279 Thanks @jorgemoya! - Stop writing CATALYST_ACCESS_TOKEN into .env.local during catalyst create. The CLI never read it back — env files are not consulted when resolving credentials — so its only effect was to imply that they are, leading users to add CATALYST_STORE_HASH alongside it and then hit "Missing credentials" from catalyst project list and catalyst deploy. .env.local now carries BIGCOMMERCE_* build variables only, and CLI configuration lives in .bigcommerce/project.json, which scaffolding already writes. Existing projects are unaffected: the stale entry is harmless and is left in place.

• #3204 bb35f22 Thanks @mfaris9! - catalyst build and catalyst deploy now run GraphQL codegen (generate) automatically, so a fresh project no longer needs a manual pnpm build before its first deploy.

@bigcommerce/create-catalyst@2.0.5

Patch Changes

• Updated dependencies [49a3432, ed8fc56, cdee279, b68192a, 02aa913, bb35f22]:
  • @bigcommerce/catalyst@1.4.0

@bigcommerce/catalyst-core@1.11.1

Patch Changes

• #3170 ccad51f Thanks @jorgemoya! - Use Cloudflare Workers KV for the routing cache on BigCommerce Native Hosting. proxies/with-routes caches redirects and storefront status through the KV abstraction in lib/kv, which previously had no Cloudflare option and silently degraded to an in-process memory cache that isn't shared across edge invocations. When the per-project CATALYST_ROUTES_KV namespace is bound to the Worker, createKVAdapter now selects a CloudflareKvAdapter. Vercel Runtime Cache still takes priority, and Upstash/memory remain the fallbacks; the binding is duck-typed so an unrelated env var of the same name falls through cleanly instead of throwing.

• #3202 715f481 Thanks @jorgemoya! - Upgrade Next.js from 16.2.11 to 16.3.4.

  16.3.3 patches two critical advisories: unauthenticated remote code execution on Windows-hosted servers (GHSA-p293-qw3h-jr36) and unauthenticated remote code execution in the Image Optimization API when AVIF files are used (GHSA-2xp9-vwfh-vxw4). 16.3.4 re-enables AVIF image optimization after that fix.

  Also picked up are backported fixes for optimistic-routing bugs that caused repeated prefetch loops, a Nav Inspector request loop on repeat captures, and cache-entry reuse that discards only entries predating a tag revalidation rather than all of them.

• #3209 f74c1f9 Thanks @mfaris9! - Product detail page date modifiers now respect the date limits set in the control panel. A Date option's earliest date, latest date, and limit mode (earliest only, latest only, or a range) now disable out-of-range days in the PDP date picker, instead of letting shoppers pick any date.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated
catalyst	Ready	Preview	Sep 11, 2026 3:39pm UTC

[github-actions]

Unlighthouse Performance Comparison — Vercel

Comparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores.

Summary Score

Aggregate score across all categories as reported by Unlighthouse.

	Prod Desktop	Prod Mobile	Preview Desktop	Preview Mobile
Score	89	93	92	95

Category Scores

Category	Prod Desktop	Prod Mobile	Preview Desktop	Preview Mobile
Performance	75	89	71	89
Accessibility	95	92	95	99
Best Practices	100	100	100	95
SEO	88	100	100	100

Core Web Vitals

Metric	Prod Desktop	Prod Mobile	Preview Desktop	Preview Mobile
LCP	3.7 s	3.5 s	5.7 s	3.8 s
CLS	0.037	0	0.039	0
FCP	1.2 s	1.5 s	1.2 s	1.2 s
TBT	0 ms	0 ms	0 ms	10 ms
Max Potential FID	40 ms	50 ms	30 ms	80 ms
Time to Interactive	3.7 s	3.5 s	5.7 s	3.8 s

Full Unlighthouse report →

[github-actions]

Bundle Size Report

Comparing against baseline from ae85df9 (2026-09-11).

No bundle size changes detected.