next.config `webpack` block silently dropped → in-browser ESLint linter breaks (assert stub, esquery ESM, rule bloat)

[hyf0]

Problem

vinext silently drops the next.config webpack block (logs [vinext] next.config option "webpack" is not yet supported and will be ignored). For react.dev this breaks the in-browser ESLint linter (the live rules-of-hooks / exhaustive-deps markers in editable Sandpacks).

react.dev's webpack block provided: resolve.alias (use-sync-external-store/shim→react, esquery→its CJS build), NormalModuleReplacement (raf, process), and an IgnorePlugin for eslint/lib/rules/*. With these gone:

Symptoms (verified with an in-chunk probe)

runESLint() returns {fatal:true, message:"Parsing error: <x> is not a function"} for all input. espree parses fine; the throw is post-parse:

1. assert — Vite maps the Node assert builtin to its empty __vite-browser-external stub, so eslint-scope's assert() is not callable ("r is not a function").
2. esquery — resolves to its ESM module entry (default-only namespace), so esquery.parse/.matches are undefined ("r.parse is not a function").
3. bundle size — without the IgnorePlugin, rolldown follows eslint/lib/rules/index.js and bundles all ~284 core rules (1.17 MB) into the lazy chunk, though only react-hooks rules are enabled.

Workaround used (vite.config)

• assert/node:assert served as a virtual CommonJS module (a .cjs file is rejected by rolldown after vite-plugin-commonjs injects export; a .js with module.exports bundles as ESM so require('assert') gets a non-callable namespace — only a virtual CJS module makes require('assert') return the callable).
• esquery aliased to esquery/dist/esquery.min.js (CJS).
• a resolveId plugin stubbing bare eslint/lib/rules/* → export default {} (1.17 MB → 542 KB).

Suggested fix

Either support a subset of next.config webpack (at least resolve.alias), or document the webpack→Vite migration for these common shims, and consider shipping a callable assert browser polyfill (Vite's empty stub silently breaks any dep that calls assert()).

[hyf0]

🔎 Triage — Next.js behavior vs vinext behavior

Method: grounded in the installed Next.js 15.1.12 source (node_modules/next/dist) and the exact vinext 0.1.8 dist (node_modules/vinext/dist) this issue was filed against; each conclusion independently re-checked by an adversarial second pass. vinext targets the Next.js 16 API surface, so a possible version difference was tested explicitly.

Verdict: 🧩 by-design limitation (Vite ≠ webpack) + vinext bug · should vinext fix: partial · scope: runtime-parity · confidence: high

Next.js behavior

Next.js fully executes the user webpack(config, ctx) function and applies its mutations (resolve.alias, plugins like IgnorePlugin/NormalModuleReplacementPlugin, loaders). Independently, for CLIENT bundles Next auto-polyfills Node core builtins by default: assert -> next/dist/compiled/assert (a real callable browser polyfill), process -> ./polyfills/process, buffer, etc. (only disabled when experimental.fallbackNodePolyfills===false). This default polyfill is why react.dev's in-browser ESLint works on real Next even though its webpack block never aliases assert — assert is callable. The esquery->CJS and use-sync-external-store/shim->react aliases are honored via resolve.alias; the IgnorePlugin trims the eslint core-rules bundle.

_{Evidence: node_modules/next/dist/build/webpack-config.js:1250-1284 (isClient resolve.fallback: assert->next/dist/compiled/assert callable, process->./polyfills/process, buffer/crypto/... by default unless experimental.fallbackNodePolyfills===false) · next.config.js:73-124 (react.dev webpack fn: resolve.alias esquery + use-sync-external-store/shim; require('webpack') for IgnorePlugin/NormalModuleReplacementPlugin; NO assert alias)}

vinext behavior

vinext does NOT fully drop the webpack block: probeWebpackConfig (next-config.js:796-831) invokes config.webpack(mockConfig, ctx) for client+server and extracts resolve.alias, resolve.extensions, and @next/mdx loader options; the extracted aliases are merged into Vite's resolve.alias (lines 640-643, 815-821). The whole probe is wrapped in try/catch returning empty aliases on any throw (line 822-829). react.dev's webpack fn calls require('webpack') (next.config.js:97), and webpack is not installed in a vinext project (verified MODULE_NOT_FOUND), so the probe throws and discards the esquery / use-sync-external-store aliases that were already set on mockConfig before the throw — so the 'not yet supported and will be ignored' warning (line 682) fires instead of the 'partially supported' one (line 681). Webpack plugins (IgnorePlugin, NormalModuleReplacementPlugin) are never honored. vinext ships no Node-builtin browser polyfill layer (no 'assert' anywhere in dist), so assert/process resolve to Vite's empty non-callable __vite-browser-external stub, breaking eslint-scope's assert() post-parse.

_{Evidence: node_modules/vinext/dist/config/next-config.js:681-682 (partial-support warning vs 'not yet supported and will be ignored') · node_modules/vinext/dist/config/next-config.js:796-831 (probeWebpackConfig extracts resolve.alias/extensions/mdx; try/catch returns empty {} on throw) · node_modules/vinext/dist/config/next-config.js:841-862 (runWebpackConfigProbe invokes config.webpack(mockConfig); only resolve.alias/extensions/rules consumed, plugins[] ignored) · node_modules/vinext/dist/config/check.js:209-211 (static check: webpack flagged 'Vite replaces webpack — custom webpack configs need migration') · node_modules/vinext/dist (grep: no 'assert'/node-builtin polyfill plugin — only async-hooks-stub; no client fallback layer)}

Is it a version difference (vinext → Next 16 vs react.dev → Next 15)?

No. Both behaviors are stable across Next 13-16. The user webpack() function has been the config surface since the early webpack-4 era, and client-side Node-builtin polyfilling via resolve.fallback (with the experimental.fallbackNodePolyfills opt-out) has existed since Next 12 (webpack-config.js:1250-1284 is unchanged across the 15.x/16 line). Nothing here changed between Next 15.1.12 and 16; the diff is Vite-vs-webpack architecture, not a version gap.

Fix

dist/config/next-config.js (probeWebpackConfig / runWebpackConfigProbe, ~796-864): make resolve.alias/extensions extraction resilient — read the mutated mockConfig.resolve.alias even when config.webpack() later throws, and/or provide a stub webpack module so require('webpack') for IgnorePlugin/NormalModuleReplacementPlugin doesn't abort the probe. Separately, add a Node-builtin client browser-polyfill layer (currently absent) mirroring Next's default client fallback (assert->callable polyfill, process, buffer, ...) so Vite's empty stub doesn't silently break deps that call assert(). Honoring arbitrary webpack plugins/loaders (IgnorePlugin rule-trim, NormalModuleReplacement) is out of scope under Vite.

Note

Refinement: vinext does not blanket-drop the webpack block — probeWebpackConfig (dist/config/next-config.js:796-831) actually invokes config.webpack(mockConfig, ctx) and harvests resolve.alias/resolve.extensions/@next/mdx options. For react.dev it loses the esquery/use-sync-external-store aliases only because the webpack fn calls require('webpack') (next.config.js:97), which MODULE_NOT_FOUNDs in a vinext project; the surrounding try/catch then discards the already-captured aliases, so the “not yet supported” warning fires instead of the “partially supported” one. Separately, the assert/process breakage is not caused by the dropped block (react.dev never aliased them) — real Next auto-polyfills Node core builtins for client bundles (assert→a callable next/dist/compiled/assert), while vinext ships no such layer so Vite's empty non-callable stub silently breaks eslint-scope's assert(). Both are fixable within vinext's own stated support surface; only the IgnorePlugin rule-trim is genuinely unsupportable under Vite.

---

_{🤖 Triaged with Claude Code (Opus 4.8) — read-only analysis against installed Next 15.1.12 + vinext 0.1.8 sources, adversarially verified.}