tsconfig `baseUrl` bare imports (no `paths`) are not resolved → ERR_MODULE_NOT_FOUND at SSR

[hyf0]

Problem

tsconfig baseUrl bare imports (with no paths) are not resolved.

react.dev's tsconfig.json sets "baseUrl": "src" and imports modules bare, e.g. import {Page} from 'components/Layout/Page'. Next/SWC resolves these. Under vinext every page 500s at SSR:

Error: Cannot find module 'components/Layout/Page' imported from src/pages/[...markdownPath].js
  code: 'ERR_MODULE_NOT_FOUND'

Root cause (from reading vinext source)

• config/tsconfig-paths.ts only materializes aliases for compilerOptions.paths — a baseUrl-only project produces zero aliases.
• config/next-config.ts only enables Vite's native resolve.tsconfigPaths when useNativeTsconfigPaths = isTypeScriptConfig && viteMajor >= 8. react.dev's config is next.config.js (not .ts), so it's disabled.
• Net: bare baseUrl roots resolve nowhere.

Workaround used

Manual resolve.alias for the bare-imported roots (components, utils, hooks) → absolute src/<root>/.

Suggested fix

Honor compilerOptions.baseUrl (bare-root resolution, not just paths) for the app, regardless of whether next.config is .js or .ts.

[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: runtime-parity · confidence: high

Next.js behavior

Next.js implements TypeScript "Absolute Imports": an explicit compilerOptions.baseUrl (e.g. "src") is read by load-jsconfig as resolvedBaseUrl={baseUrl:/src, isImplicit:false}, and getBaseWebpackConfig pushes that directory onto webpackConfig.resolve.modules. Webpack then resolves a bare import like components/Layout/Page by searching src/ (treating baseUrl like an extra module root), with NO paths entry required. The JsConfigPathsPlugin only handles paths and explicitly bails when paths is empty, so baseUrl-only resolution is done entirely via resolve.modules. This is a long-standing, stable Next feature (13–16).

_{Evidence: node_modules/next/dist/build/load-jsconfig.js:136-140 (explicit baseUrl => {baseUrl:resolve(dir,baseUrl), isImplicit:false}) · node_modules/next/dist/build/webpack-config.js:1582-1584 (if resolvedBaseUrl && !isImplicit, push resolvedBaseUrl.baseUrl onto resolve.modules) · node_modules/next/dist/build/webpack/plugins/jsconfig-paths-plugin.js:165-168 (paths plugin bails out when pathsKeys.length===0 — so it is NOT what resolves baseUrl-only imports) · https://nextjs.org/docs/app/building-your-application/configuring/absolute-imports-and-module-aliases (baseUrl alone enables absolute imports)}

vinext behavior

vinext only materializes Vite resolve.alias entries for compilerOptions.paths. In the app config hook (dist/index.js), resolveTsconfigAliases→loadTsconfigPathAliases returns if (!pathsConfig) return aliases (line 259), so a baseUrl-only tsconfig produces ZERO aliases; baseUrl is used solely as the base for resolving paths targets (lines 260-264). The assembled resolve.alias (lines 882-885) therefore contains no bare-root entry for components/utils/hooks. vinext does enable Vite's native resolve.tsconfigPaths when viteMajor>=8 (lines 637, 892) — and react.dev runs Vite 8.1.0, so it IS enabled, regardless of next.config being .js (the issue's ".js disables it" reasoning is only true for the separate next.config-FILE loader at config/next-config.js:292, not the app). But Rolldown/oxc native tsconfigPaths does not cover baseUrl-only bare imports, so every page still 500s with ERR_MODULE_NOT_FOUND at SSR (empirically confirmed; workaround was a manual resolve.alias for the 3 bare roots). vinext has no equivalent of Next's resolve.modules baseUrl push.

_{Evidence: node_modules/vinext/dist/index.js:257-259 (loadTsconfigPathAliases: pathsConfig=compilerOptions.paths; if(!pathsConfig) return aliases — baseUrl-only yields no aliases) · node_modules/vinext/dist/index.js:260-264 (baseUrl only used as resolution base for materializing paths) · node_modules/vinext/dist/index.js:637 (shouldEnableNativeTsconfigPaths = viteMajorVersion>=8 && userResolve?.tsconfigPaths===undefined — NOT gated on .ts) · node_modules/vinext/dist/index.js:882-892 (resolve.alias = {...tsconfigPathAliases, ...nextConfig.aliases, ...nextShimMap}; tsconfigPaths:true conditionally) · node_modules/vinext/dist/config/tsconfig-paths.js:118-123 (config-file loader: baseUrl captured but if(!pathsConfig) return {aliases, baseUrl} — no bare-root aliases) · node_modules/vinext/dist/config/next-config.js:292 (useNativeTsconfigPaths gated on isTypeScriptConfig — applies ONLY to loading the next.config file, not the app) · FINDINGS.md:84 (empirical: 'native resolve.tsconfigPaths doesn't cover baseUrl-only in the SSR runner'; fix = manual resolve.alias for components/utils/hooks)}

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

No. TypeScript baseUrl 'Absolute Imports' is a stable Next feature across 13–16. Next's mechanism — pushing the resolved baseUrl onto webpack resolve.modules — predates Next 15 and is unchanged in 16 (the webpack-config.js:1582-1584 push and load-jsconfig isImplicit logic are not part of any 15→16 changelog item). The diff is not because vinext targets Next 16; baseUrl-only bare imports would fail under vinext against any Next version, so this is a genuine parity defect, not a version difference.

Fix

node_modules/vinext/dist/index.js — loadTsconfigPathAliases/materializeTsconfigPathAliases (lines 205-266) plus the vinext:config resolve.alias assembly (lines 636-638, 880-892), and the mirrored dist/config/tsconfig-paths.js for next.config loading. vinext must honor compilerOptions.baseUrl bare-root resolution (Next's resolve.modules equivalent) independent of paths and independent of whether next.config is .js or .ts — e.g. by registering baseUrl as a resolution root / synthesizing bare-root aliases, since native tsconfigPaths does not cover baseUrl-only.

Note

Correction to the issue's root-cause: the “next.config is .js → native resolve.tsconfigPaths disabled” reasoning is inaccurate for the app build. The app gate is viteMajor >= 8 only (dist/index.js:637), and react.dev runs Vite 8.1.0, so native tsconfigPaths is enabled here. The isTypeScriptConfig && viteMajor>=8 .ts-gating lives in dist/config/next-config.js:292, which only governs loading the next.config FILE itself, not app module resolution. The real reason bare baseUrl roots fail is that Rolldown/oxc native tsconfigPaths doesn't cover baseUrl-only (no paths) resolution, and vinext has no equivalent of Next's resolve.modules baseUrl push. The observed failure and the fix (honor baseUrl bare-root resolution) are unchanged.

---

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