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.

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.

• #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, b68192a, 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.

[vercel]

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

Project	Deployment	Actions	Updated
catalyst	Ready	Preview	Sep 3, 2026 8:54pm 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	90	93	91	95

Category Scores

Category	Prod Desktop	Prod Mobile	Preview Desktop	Preview Mobile
Performance	74	91	71	92
Accessibility	95	92	95	92
Best Practices	100	100	100	100
SEO	88	100	100	100

Core Web Vitals

Metric	Prod Desktop	Prod Mobile	Preview Desktop	Preview Mobile
LCP	3.9 s	3.3 s	5.4 s	3.3 s
CLS	0.037	0	0.039	0
FCP	1.2 s	1.4 s	1.2 s	1.2 s
TBT	30 ms	20 ms	0 ms	0 ms
Max Potential FID	70 ms	90 ms	40 ms	40 ms
Time to Interactive	3.9 s	4.3 s	5.4 s	3.3 s

Full Unlighthouse report →