sync integrations/makeswift with canary#2991
Open
jorgemoya wants to merge 11 commits intointegrations/makeswiftfrom
Open
sync integrations/makeswift with canary#2991jorgemoya wants to merge 11 commits intointegrations/makeswiftfrom
integrations/makeswift with canary#2991jorgemoya wants to merge 11 commits intointegrations/makeswiftfrom
Conversation
* fix: split regression-tests workflow into two separate flows * fix: merge back to a single file * use deployments.ref for PRs
* feat(other): LOCAL-1444 delivery translation * chore(core): create translations patch --------- Co-authored-by: bc-svc-local <bc-svc-local@users.noreply.github.com>
* chore: add deployment for native hosting * chore: fix native hosting workflow for alpha CLI - Remove pull_request trigger (no preview deployments) - Add concurrency group to prevent parallel deploys - Remove jq package.json mutation, use pnpm exec directly - Add separate generate step for GraphQL types - Fix env vars to CATALYST_* namespace for CLI commands - Remove --framework flag (removed in alpha) - Add --prebuilt to deploy (skip redundant build) - Add BIGCOMMERCE_API_HOST for integration API --------- Co-authored-by: Matthew Volk <matt.volk@bigcommerce.com>
…ityId (#2963) The DynamicFormField switch statement had no case for 'hidden' field types, causing hidden inputs (pageId, pagePath) to never render in the DOM. On form submission, these missing values produced undefined, which Number() converted to NaN, failing Zod validation. Refs: TRAC-292 Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* feat(core): add X-Correlation-ID header to all GraphQL requests Each page render gets a stable UUID (via React.cache) that persists across all fetches within the same render, enabling easier request tracing in server logs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * fix(core): wrap correlation-id import in try/catch for config resolution The dynamic import of correlation-id.ts fails during next.config.ts resolution because React.cache is unavailable in that context. Wrap in try/catch to match the existing pattern for next-intl/server. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * chore: change correlation-id changeset to patch Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
… config (#2983) Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
The spec files for the `build`, `dev`, and `start` CLI commands asserted that execa was called with `'node_modules/.bin/next'` (and `'.bigcommerce/wrangler.jsonc'` in the OpenNext case) using POSIX separators. Production code builds these paths via Node's `path.join`, which returns `\`-separated paths on Windows, so the assertions fail on `CLI Tests (windows-latest)`. Import `join` in each spec and build the expected path the same way the production code does, so the assertions match regardless of OS. Fixes LTRAC-594 Co-authored-by: Claude <noreply@anthropic.com>
The root <html> tag was hardcoded to lang="en" for all locales because
a new root app/layout.tsx to enable the branded /404 page. That fix
solved the 404 but regressed the lang attribute.
Adopt next-intl's documented pattern:
- app/layout.tsx is now a passthrough (returns children) — required by
Next.js but owns no markup.
- app/[locale]/layout.tsx owns <html lang={locale}> and <body> again,
so localized pages get the correct language.
- app/not-found.tsx owns its own <html>/<body>, fonts, and global CSS
so the branded 404 still renders for non-localized requests.
Verified parity with canary on runtime 404 behavior (both serve the
Next.js error-fallback shell for dynamic 404s) and clean output in the
prerendered _not-found.html static file.
Fixes LTRAC-578
LTRAC-578: chore - Bump changeset to minor
Restructures <html>/<body> ownership across root layout, [locale]
layout, and not-found — customers who customized these files will need
to migrate, so a minor bump is more appropriate than patch.
Refs LTRAC-578
LTRAC-578: docs - Add TODO for rootParams migration
Note that the passthrough root layout is a workaround — once
Next.js `rootParams` (16.2+) is available on Native Hosting, we
should move <html>/<body> back here and derive `lang` from rootParams.
Refs LTRAC-578
Co-authored-by: Claude <noreply@anthropic.com>
* feat(other): LOCAL-1444 delivery translation * chore(core): create translations patch --------- Co-authored-by: bc-svc-local <bc-svc-local@users.noreply.github.com>
…akeswift # Conflicts: # core/app/layout.tsx
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Contributor
Bundle Size ReportComparing against baseline from
Per-Route First Load JS
|
Contributor
Unlighthouse Performance Comparison — VercelComparing PR preview deployment Unlighthouse scores vs production Unlighthouse scores. Summary ScoreAggregate score across all categories as reported by Unlighthouse.
Category Scores
Core Web Vitals
|
agurtovoy
reviewed
Apr 24, 2026
| </head> | ||
| <body className="flex min-h-screen flex-col">{children}</body> | ||
| </html> | ||
| <SiteTheme /> |
Contributor
There was a problem hiding this comment.
We're currently not passing the current locale to MakeswiftProvider, but we really should.
With that in mind, I think we should go back to the arrangement we had prior to this back & forth change and have <MakeswiftProvider> live in the locale-specific root layout: https://github.com/bigcommerce/catalyst/blame/91d8da7a30afe6fe2e6d8aca41bcb2d061ecf048/core/app/%5Blocale%5D/layout.tsx#L149
If we want <SiteTheme /> to be applied to the 404 page, we can do it explicitly there:
<MakeswiftProvider siteVersion={siteVersion}>
<SiteTheme />
</MakeswiftProvider>
Contributor
Author
There was a problem hiding this comment.
Good point — addressed in 9dff9d8.
MakeswiftProvidernow lives inapp/[locale]/layout.tsxand receiveslocale(threaded through toReactRuntimeProvider).- Root
app/layout.tsxis back to canary's pass-through. app/not-found.tsxwraps its own tree with<MakeswiftProvider siteVersion={siteVersion}><SiteTheme /></MakeswiftProvider>so the 404 still picks up the theme tokens (nolocalethere since we're outside[locale]).
Addresses review feedback on #2991: `MakeswiftProvider` needs the active `locale` (per Makeswift ReactRuntimeProvider docs), so move the provider into `app/[locale]/layout.tsx` where `locale` is available and forward it through. Root `app/layout.tsx` stays as canary's pass-through. The 404 page (`app/not-found.tsx`) wraps its own tree with `MakeswiftProvider` + `<SiteTheme />` explicitly so the branded theme still applies outside `[locale]`. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Merges the latest
canaryintointegrations/makeswift. Brings in the following from canary:e18feb6dd— Update translations (Update translations #2987)518d20a8a— fix(core): restore locale-aware lang attribute on html (fix(core): restore locale-aware lang attribute on html #2989)225c4ef4d— test(cli): make path assertions OS-agnostic (test(cli): make path assertions OS-agnostic #2990)be980dace— fix: exclude /brands path and add PLP brands sampling to unlighthouse config (fix: exclude /brands path and add PLP brands sampling to unlighthouse config #2983)a85fa42aa— feat(core): add X-Correlation-ID header to all GraphQL requests (feat(core): add X-Correlation-ID header to all GraphQL requests #2976)a8dd99ef9— fix(core): render hidden fields in DynamicForm to prevent NaN pageEntityId (fix(core): TRAC-292 render hidden fields in DynamicForm #2963)09f649b7a— chore: add deployment for native hosting (chore: add deployment for native hosting #2835)4870221c3— Update translations (Update translations #2959)1a2b1426a— fix: improve regression-tests workflow structure and concurrency (fix: improve regression-tests workflow structure and concurrency #2948)Conflict resolutions
core/app/layout.tsx— Canary moved<html>/<body>ownership out of the root layout intoapp/[locale]/layout.tsx(see fix(core): restore locale-aware lang attribute on html #2989). Makeswift-specific wiring (getSiteVersion(),MakeswiftProvider,SiteTheme, and the~/lib/makeswift/componentsregistration import) was preserved and now wraps{children}at the root level.MakeswiftProvideris a client Context andSiteThemerenders<style>tags that React 19 hoists to<head>, so they work correctly without owning the<html>element.Changeset cleanup
Removed 5 changesets that targeted
@bigcommerce/catalyst-core(not@bigcommerce/catalyst-makeswift):correlation-id-header.mdfix-hidden-fields-d35665be.mdfix-html-lang-locale.mdtranslations-patch-d3abeec7.mdtranslations-patch-e3d3b994.mdPackage metadata (verified unchanged)
core/package.jsonname:@bigcommerce/catalyst-makeswiftcore/package.jsonversion:1.6.3(matches latest published tag)core/CHANGELOG.mdlatest entry:## 1.6.3