JSX in `.js` files breaks the optimizeDeps dependency scanner

[hyf0]

Problem

JSX in .js files breaks the Vite 8 / rolldown optimizeDeps dependency scanner.

react.dev keeps JSX in plain .js files (pages/404.js, pages/[[...markdownPath]].js, components/Layout/HomeContent.js, utils/prepareMDX.js, …) — Next/SWC handles this. vinext's main oxc transform handles it for SSR too, but the dep scanner has JSX disabled for .js:

(!) Failed to run dependency scan. Skipping dependency pre-bundling.
[PARSE_ERROR] Unexpected JSX expression
  Help: JSX syntax is disabled and should be enabled via the parser options

This is non-fatal at boot but cascades: with pre-bundling skipped, UMD/CJS deps (e.g. classnames) aren't interop'd and then crash under SSR (window is not defined).

Workaround used

optimizeDeps: { rolldownOptions: { moduleTypes: { '.js': 'jsx' } } }

Suggested fix

vinext should configure the optimizeDeps scanner to treat the app's .js as JSX (mirroring how it already treats .js for the main transform), so apps with JSX-in-.js pre-bundle correctly out of the box.

[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) · should vinext fix: yes · scope: dev-only · confidence: high

Next.js behavior

Next.js/SWC parses JSX in plain .js files everywhere by default. getParserOptions sets syntax 'ecmascript' for non-TS files and enables jsx parsing for any non-.ts file (jsx: !isTSFile), so .js/.jsx/.mjs are all treated as JSX. Next bundles via webpack/turbopack with the SWC loader applied uniformly to every module it crawls — there is no separate Vite-style optimizeDeps pre-bundle dependency scanner that could parse a .js without JSX enabled. Result: react.dev's JSX-in-.js files (pages/404.js, pages/[[...markdownPath]].js, components/Layout/HomeContent.js, utils/prepareMDX.js) compile transparently with no .jsx extension requirement and no scan failure.

_{Evidence: node_modules/next/dist/build/swc/options.js:58 · node_modules/next/dist/build/swc/options.js:62 · node_modules/next/dist/build/swc/options.js:51-65}

vinext behavior

vinext handles JSX-in-.js for its MAIN transform pipeline via the 'vinext:jsx-in-js' plugin (enforce:'pre'), which calls transformWithOxc(code, id, { lang:'jsx', jsx:{runtime:'automatic'} }) for every .js/.mjs (app files unconditionally; node_modules files only with a use client/use server React directive). That makes SSR and the client build work. However, Vite 8's rolldown optimizeDeps dependency SCANNER runs separately, using only optimizeDeps.rolldownOptions, which vinext builds as { transform:{define}, plugins:[depOptimizeAliasPlugin] } — it does NOT include moduleTypes, and the main 'vinext:jsx-in-js' transform plugin is not part of the scanner's plugin list. The top-level oxc.jsx.runtime:'automatic' (index.js:894) only governs the main transform, not the scan parser. With JSX parsing left off for .js in the scanner, rolldown throws [PARSE_ERROR] Unexpected JSX expression, the scan aborts, and dependency pre-bundling is skipped (non-fatal at boot but cascading to CJS/UMD interop failures like classnames -> 'window is not defined' under SSR). 'moduleTypes' appears nowhere in the entire vinext dist. The documented workaround optimizeDeps.rolldownOptions.moduleTypes: { '.js':'jsx' } is exactly the knob vinext omits. Dev/serve-time only (build path uses the main transform and works).

_{Evidence: node_modules/vinext/dist/index.js:597-619 · node_modules/vinext/dist/index.js:933-941 · node_modules/vinext/dist/index.js:894 · node_modules/vinext/dist/index.js:961 · node_modules/vinext/dist/index.js:984 · node_modules/vinext/dist/index.js:996 · node_modules/vinext/dist/utils/vite-version.js:16-18}

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

No. Next/SWC enabling JSX parsing for all .js files is long-stable behavior (getParserOptions sets jsx: !isTSFile regardless of Next 13/14/15/16); options.js:62 shows it in the installed 15.1.12, and it is not a 15->16 change. The diff is purely vinext's own pipeline asymmetry: its main 'vinext:jsx-in-js' oxc transform enables JSX for .js but its optimizeDeps scanner config omits moduleTypes. Nothing about this depends on vinext targeting the Next 16 API surface.

Fix

dist/index.js optimizeDeps wiring (the config() hook): add moduleTypes { '.js':'jsx', '.mjs':'jsx' } to optimizeDeps.rolldownOptions at index.js:933-941 and to the per-environment optimizeDeps blocks at index.js:961/984/996, mirroring the existing 'vinext:jsx-in-js' main-transform plugin (index.js:597-619).

---

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

[hyf0]

Fixed upstream: cloudflare/vinext#2434 (fix(dev): treat .js as JSX in the optimizeDeps scanner), merged. Lands in the next vinext release (after 0.2.0), so this port keeps the optimizeDeps.rolldownOptions.moduleTypes { '.js': 'jsx' } workaround until it upgrades past 0.2.0. Closing as fixed upstream.