fix: throw errors when next config file loading fails

[james-elicx]

failures loading a Next.js config (e.g. due to CJS require statements) should fail a build, otherwise it produces an output that disregards the user's configuration (e.g. pageExtensions), creating incorrect/invalid bundles and giving a confusing experience.

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/vinext@593

commit: d6fe022

[github-actions]

Example	Preview	Production	Original
app-router-cloudflare	preview	production
pages-router-cloudflare	preview	production
app-router-playground	preview	production	original
realworld-api-rest	preview	production
nextra-docs-template	preview	production
benchmarks	preview	production
hackernews	preview	production	original

[james-elicx]

/bigbonk review

[ask-bonk]

LGTM. The behavioral change is correct — silently returning null when a config file exists but fails to load produces builds that ignore user configuration, which is a worse failure mode than a clear error.

What I verified:

1. Both throw sites are appropriate. The first (line 343) covers the CJS fallback failing after the initial ESM load failed with a CJS error. The second (line 348) covers non-CJS errors (syntax errors, missing imports, plugin crashes) or errors from .mjs/.ts files that don't get the CJS retry. Neither changes the return null at line 352 when no config file exists — that's still correct.

2. Callers are fine with the throw. All four call sites (index.ts:1515, deploy.ts:1282, run-prerender.ts:131, cli.ts:498) don't try-catch loadNextConfig, so the error propagates to Vite's plugin system or the CLI's top-level handler, which is the right behavior — a broken config should halt the build.

3. Existing CJS happy-path tests are unaffected. The tests in shims.test.ts (lines 7077-7213) exercise cases where the CJS fallback succeeds, so the throw in the fallback's catch block is never reached in those tests.

4. console.error is appropriate. Since this is now a fatal error, console.error is the right log level. The warnConfigLoadFailure call before the throw provides context (including the next-intl hint when relevant), and the thrown error will be caught by the caller's error handler for its own output. The blank lines around the error message improve readability in terminal output.

One minor note: the test covers CJS-in-ESM-context specifically ("type": "module" + require()). It would be reasonable to also test a config with a genuine syntax error or a missing import to exercise the non-CJS throw path, but that's not blocking — the logic is straightforward and the existing test validates the core contract change.

[ask-bonk]

Reviewed and approved PR #593. The change is correct — throwing on config load failure is strictly better than silently returning null, which would produce builds that ignore user configuration (e.g., pageExtensions). All four call sites let the error propagate to appropriate error handlers. Existing CJS happy-path tests are unaffected since the throw only triggers when the fallback itself fails.

github run