`.cjs` configs from `vinext init` renames aren't in Vite's default `resolve.extensions` → extensionless config import fails

[hyf0]

Problem

After vinext init renames tailwind.config.js/postcss.config.js to .cjs (required under "type": "module"), app code that imports the config extensionlessly fails to resolve, because Vite's default resolve.extensions does not include .cjs.

react.dev's src/components/MDX/Sandpack/Themes.tsx does:

import tailwindConfig from '../../../../tailwind.config';

Build error:

[UNRESOLVED_IMPORT] Could not resolve '../../../../tailwind.config' in Themes.tsx

Workaround used

resolve.extensions: ['.mjs', '.js', '.cjs', '.mts', '.ts', '.jsx', '.tsx', '.json'] (add .cjs). (We later converted the tailwind config to .mjs ESM for a separate reason — importing a .cjs into the bundle is itself awkward: rolldown rejects a .cjs after vite-plugin-commonjs injects export into it.)

Suggested fix

Since vinext init is what renames these configs to .cjs, it should also ensure .cjs resolves (add it to resolve.extensions, or generate an importable ESM config).

[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: 🛠️ tooling / UX gap + vinext bug · should vinext fix: yes · scope: init-tooling · confidence: high

Next.js behavior

Under real Next.js 15.1.12, react.dev keeps tailwind.config.js/postcss.config.js as plain .js CommonJS files — Next does not force "type":"module" and never renames them. Next's webpack resolver default resolve.extensions is ['.js', '.mjs', '.tsx', '.ts', '.jsx', '.json', '.wasm'], so the extensionless static import import tailwindConfig from '../../../../tailwind.config' in Themes.tsx resolves to tailwind.config.js. (Note: webpack's default extensions also exclude .cjs, but the file never becomes .cjs under Next, so it never matters.)

_{Evidence: node_modules/next/dist/build/webpack-config.js:507-517 (resolveConfig.extensions = ['.js','.mjs','.tsx','.ts','.jsx','.json','.wasm'])}

vinext behavior

vinext init runs renameCJSConfigs(root) then ensureESModule(root): it adds "type":"module" to package.json and renames any .js config whose body contains module.exports/require( to .cjs — and tailwind.config.js/postcss.config.js are both in the CJS_CONFIG_FILES list (utils/project.js:11-21, 45-61). The vite.config.ts it generates (generateViteConfig, init.js:26-34) contains only plugins:[vinext()] and NO resolve.extensions override. Vite's default resolve.extensions is ['.mjs','.js','.mts','.ts','.jsx','.tsx','.json'] — no .cjs — and vinext's buildViteResolveExtensions only ever appends user pageExtensions to that list, never .cjs (file-matcher.js:97-115). The extensionless-dynamic-import plugin's candidate list also excludes .cjs and only transforms dynamic import() calls, not static imports (extensionless-dynamic-import.js:5-13, 32-39). Net: after init renames tailwind.config.js→tailwind.config.cjs, the unchanged extensionless static import '.../tailwind.config' becomes unresolvable and the build fails with [UNRESOLVED_IMPORT]. The current app state already shows the manual workaround: tailwind.config.mjs (resolvable via the .mjs default) plus postcss.config.cjs.

_{Evidence: node_modules/vinext/dist/init.js:26-34 (generateViteConfig emits only plugins:[vinext()], no resolve.extensions) · node_modules/vinext/dist/init.js:217-218 (renameCJSConfigs then ensureESModule) · node_modules/vinext/dist/utils/project.js:11-21 (CJS_CONFIG_FILES includes postcss.config.js, tailwind.config.js) · node_modules/vinext/dist/utils/project.js:45-61 (renameCJSConfigs: .js -> .cjs when module.exports/require present) · node_modules/vinext/dist/routing/file-matcher.js:97-115 (buildViteResolveExtensions: Vite defaults exclude .cjs; only pageExtensions appended) · node_modules/vinext/dist/plugins/extensionless-dynamic-import.js:5-13,32-39 (candidate extensions exclude .cjs; only dynamic import() handled)}

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

No. This is not a Next 15->16 behavior change. Webpack's default resolve.extensions (next/dist/build/webpack-config.js:507-517) and Vite's default resolve.extensions (file-matcher.js:98-104) are both stable and neither includes .cjs across the relevant versions. The breakage is caused entirely by vinext init's own side effect of forcing type:module and renaming the .js config to .cjs without making .cjs resolvable — it has nothing to do with which Next version is targeted.

Fix

dist/init.js generateViteConfig should add '.cjs' to resolve.extensions whenever it renames CJS configs to .cjs; more robustly, the core vinext() plugin / routing/file-matcher.js buildViteResolveExtensions should always include '.cjs' in Vite's resolve.extensions (since vinext itself produces .cjs configs via renameCJSConfigs, and the lazy ensureViteConfigCompatibility path renames too) — or init should generate an importable ESM config instead of a bare rename.

---

_{🤖 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#2435 (fix(config): resolve and bundle extensionless .cjs config imports), merged. Lands in the next vinext release (after 0.2.0), so this port keeps .cjs in resolve.extensions until it upgrades. Closing as fixed upstream.