`vinext dev` SSR module-runner doesn't CJS-interop UMD/CJS deps (classnames `window`, parse-numeric-range `exports`)

[hyf0]

Problem

vinext dev is unusable for react.dev: the SSR module-runner inlines externalized deps without CJS interop, so common UMD/CJS deps throw at module eval.

Repro (npm run dev:vinext, then GET any page)

• classnames (UMD, module.exports inside an IIFE) → ReferenceError: window is not defined at classnames/index.js.
• parse-numeric-range (CJS) → ReferenceError: exports is not defined.
• Result: every page 500s in dev.

vinext build + vinext start are fine — rolldown's full bundle interops these correctly. The problem is specific to the dev module-runner's on-demand inlining.

Workaround used (partial)

optimizeDeps.include / ssr.optimizeDeps.include for the offending deps — but this is whack-a-mole; any UMD/CJS dep with IIFE-wrapped module.exports hits it.

Suggested fix

The dev SSR module-runner should apply CJS→ESM interop to inlined node_modules deps (detecting module.exports/exports even inside an IIFE), matching the build path.

[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: 🐞 vinext bug (parity gap — fix needed) + by-design limitation · should vinext fix: yes · scope: dev-only · confidence: high

Next.js behavior

Real Next.js 15.1.12 makes these deps work in dev. The Pages Router client compiles everything through webpack/SWC with CJS->ESM interop helpers (_interop_require_default/_interop_require_wildcard), and on the server, dependencies are either bundled the same way or externalized and loaded by Node's native require(), which provides module/exports/define so a UMD wrapper like classnames resolves its typeof module !== 'undefined' && module.exports branch and never falls through to the window.classNames branch. Either path supplies CJS scaffolding, so classnames (UMD) and parse-numeric-range (CJS) evaluate without ReferenceErrors. This is stable webpack/Node behavior, not version-specific.

_{Evidence: node_modules/next/dist/build/webpack-config.js:2 (Object.defineProperty(exports, "__esModule")) and :55 (_interop_require_default(require(...))) — Next compiles modules with CJS interop helpers · node_modules/next/dist/compiled/@babel/runtime/helpers/interopRequireDefault.js:1 (_interopRequireDefault) — interop helper shipped/used by Next · node_modules/classnames/index.js:47-56 — UMD: module.exports branch, else define.amd, else window.classNames (the fallback that throws when no module/exports/define in scope)}

vinext behavior

In dev for a Pages Router app (react.dev), vinext's config hook injects an ssr Vite environment with resolve.noExternal: true (only react/react-dom/react-dom/server/ipaddr.js + serverExternalPackages are externalized), forcing every other node_modules dep to be INLINED into Vite's SSR module graph. CJS->ESM interop for those inlined deps only occurs if optimizeDeps pre-bundles them (rolldown/esbuild). vinext's ssr optimizeDeps only sets exclude:[ipaddr.js] + entries and passes through user include — it does not guarantee arbitrary CJS deps are pre-bundled. When the optimizeDeps scanner does not discover a dep (e.g. react.dev keeps JSX in .js files, which the scanner skips — FINDINGS BLK-2), the dep is fetched via DevEnvironment.fetchModule and evaluated by the module runner's ESModulesEvaluator with NO module/exports/define in scope. classnames (UMD) then falls through to window.classNames -> window is not defined; parse-numeric-range (CJS, module.exports = parsePart) -> exports is not defined. Every affected page 500s. vinext build+start are unaffected because the build path bundles via rolldown (withBuildBundlerOptions -> rolldownOptions on Vite 8) with full native CJS interop. Workaround: add the deps to optimizeDeps.include / ssr.optimizeDeps.include (whack-a-mole).

_{Evidence: node_modules/vinext/dist/index.js:1050-1064 — shouldInjectPlainPagesEnvironments ssr env: resolve.external=[react,react-dom,react-dom/server,ipaddr.js,...nextServerExternal], noExternal:true; optimizeDeps.exclude=['ipaddr.js'] only · node_modules/vinext/dist/index.js:878 and :982 — noExternal:true also set on the top-level/app ssr config blocks · node_modules/vinext/dist/server/dev-module-runner.js:71-89 — createDirectRunner builds a ModuleRunner whose transport calls environment.fetchModule() and evaluates with ESModulesEvaluator (no CJS scaffolding/interop layer) · node_modules/vinext/dist/index.js:847 and :969,1012,1043,1067 — withBuildBundlerOptions -> rolldownOptions/rollupOptions for the build path (full CJS interop, why build+start work) · node_modules/parse-numeric-range/index.js (tail): exports.default = parsePart; module.exports = parsePart; (pure CJS) — throws 'exports is not defined' under ESM eval}

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

No. This is not a Next 15->16 behavioral change. CJS/UMD dependency interop in dev is stable across Next 13-16 (webpack bundles node_modules with interop_require* helpers; the server require() path handles CJS natively). The diff is caused entirely by vinext's Vite-based dev architecture choice (ssr.noExternal:true + an ESM-only module runner that relies on optimizeDeps for interop), not by which Next version is targeted. No Next changelog entry governs this; classnames 2.3.1 UMD and parse-numeric-range 1.x are unchanged.

Fix

Dev SSR pipeline: index.js ssr env config (noExternal:true at index.js:1059 / :878 / :982 combined with optimizeDeps at index.js:1061-1064 / :984-988) and server/dev-module-runner.js (ESModulesEvaluator path). Fix: guarantee CJS->ESM interop for inlined node_modules in dev — either reliably pre-bundle discovered CJS deps (robust optimizeDeps scan incl. JSX-in-.js), provide a CJS-interop fallback in the module runner matching the rolldown build path, or default to externalizing node_modules in the Node dev SSR env instead of noExternal:true.

---

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