LTRAC-1420: Fix OpenNext buildCommand failing on native Windows - #3159
Open
jorgemoya wants to merge 1 commit into
Open
LTRAC-1420: Fix OpenNext buildCommand failing on native Windows#3159jorgemoya wants to merge 1 commit into
jorgemoya wants to merge 1 commit into
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
🦋 Changeset detectedLatest commit: 5e757e1 The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
Contributor
Bundle Size ReportComparing against baseline from No bundle size changes detected. |
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
|
…indows The generated open-next.config.ts hardcoded 'node_modules/.bin/next build' as its buildCommand. OpenNext runs this via execSync, which shells out to cmd.exe on native Windows — where the extensionless POSIX shim and forward-slash path both fail to resolve, breaking catalyst build/deploy. Invoke 'node ./node_modules/next/dist/bin/next build' instead, which works identically across sh and cmd.exe while still skipping the project's generate step. Refs LTRAC-1420 Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
jorgemoya
force-pushed
the
jorgemoya/ltrac-1420-opennext-windows-buildcommand
branch
from
August 6, 2026 19:07
c6aa972 to
5e757e1
Compare
jorgemoya
marked this pull request as ready for review
August 6, 2026 19:09
parthshahp
approved these changes
Aug 6, 2026
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
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.
Linear: LTRAC-1420
What/Why?
A closed-beta partner (Vortex IQ) hit a hard failure running
catalyst deploy/catalyst buildon native Windows during the OpenNext step, and had to move the build to WSL to proceed. Localpnpm devworked — only the OpenNext/Native Hosting build path failed.Root cause is a single line in the generated OpenNext config template (
packages/catalyst/templates/open-next.config.ts):OpenNext executes this string via
@opennextjs/aws'sbuildNextjsApp(), which callscp.execSync(command, ...).execSyncruns through the system shell —/bin/shon Unix butcmd.exeon Windows. Under cmd.exe that command fails two ways:/as a switch character and can't resolvenode_modules/.bin/nextas the command token.next.cmd/next.ps1; the extensionless.bin/nextis a POSIXshscript cmd.exe can't execute.This template is only used on the OpenNext/Cloudflare deploy path (copied into
.bigcommerce/bybuild.tsbefore the build), which is whynext dev— routed through the package.json scripts and the pnpm/npm.cmdshims — works fine while the deploy build breaks.The fix invokes Next through
nodeon its published bin:noderesolves on PATH on every platform and node.exe accepts forward-slash paths, so this runs identically undershandcmd.exe. It's exactly what the.cmd/shshims exec internally, so behavior is unchanged — it still runsnext builddirectly and deliberately skips the project'sgeneratestep (the reasonbuildCommandis hardcoded rather than deferring to thebuildscript, which isnpm run generate && next build).Only the template changes;
core/.bigcommerce/open-next.config.tsis a gitignored copy regenerated on every build.Testing
@opennextjs/aws@3.9.16/dist/build/buildNextApp.jsrunsconfig.buildCommandviacp.execSync(command, { stdio: 'inherit', cwd })(shell → cmd.exe on Windows).next'sbinis./dist/bin/nextand that the new command is equivalent to what the.binshims exec.catalyst build/catalyst deploycontinue to build via OpenNext unchanged.catalyst deploycompletes end-to-end without WSL.Migration
None. Config is regenerated on each build; no consumer action required.