`getTypeScriptConfiguration`: TypeScript 6 path rewriting deletes `baseUrl` but does not update `pathsBasePath`, breaking module resolution in monorepos with shared base tsconfig

[gardsa]

Link to the code that reproduces this issue

https://github.com/gardsa/my-minimal-nextjs-issue-reproduction

To Reproduce

1. Clone the reproduction repository (linked above)
2. From the repo root, install dependencies:

   npm install

3. Run the build from the app directory:

   cd apps/my-app && npx next build

4. Observe that Turbopack/webpack compilation succeeds but the TypeScript type-check step immediately after fails:

   Type error: Cannot find module '@scope/shared-lib/index' or its corresponding type declarations.
   

Current vs. Expected behavior

Expected: next build completes successfully. Path aliases defined in the shared tsconfig.base.json resolve correctly for both webpack and the TypeScript type-checker.

Actual: Webpack/Turbopack compilation succeeds, but the TypeScript check step that runs immediately after fails:

Running TypeScript ...
Failed to type check.

./src/app/page.tsx:1:26
Type error: Cannot find module '@scope/shared-lib/index' or its corresponding type declarations.

This affects every path alias defined in the shared base tsconfig. Aliases defined directly in the app-level tsconfig are not affected.

Provide environment information

Operating System:
  Platform: linux
  Arch: arm64
Binaries:
  Node: 24.14.1
  npm: 11.11.0
  Yarn: 1.22.22
Relevant Packages:
  next: 16.2.4
  react: 19.2.5
  react-dom: 19.2.5
  typescript: 6.0.3

Which area(s) are affected? (Select all that apply)

TypeScript, Module Resolution

Which stage(s) are affected? (Select all that apply)

next build (local)

Additional context

Root cause

getTypeScriptConfiguration.js adds a TypeScript 6 compatibility block that rewrites paths to be relative to the app dir and deletes baseUrl:

if (semver.gte(typescript.version, '6.0.0')) {
    const parsedBaseUrl = result.options.baseUrl;
    if (typeof parsedBaseUrl === 'string' && parsedBaseUrl.length > 0) {
        const normalizedBaseUrl = getNormalizedBaseUrlForPaths(parsedBaseUrl, tsConfigPath);
        result.options.paths = rewritePathAliasesWithoutBaseUrl(normalizedBaseUrl, result.options.paths);
        delete result.options.baseUrl;
        // ← pathsBasePath is NOT updated here
    }
}

For an app at apps/my-app/, normalizedBaseUrl is '../..', so "libs/shared-lib/src/*" becomes "../../libs/shared-lib/src/*" — correct relative to the app dir.

After baseUrl is deleted, TypeScript's module resolver calls getPathsBasePath:

// typescript/lib/typescript.js
function getPathsBasePath(options, host) {
    if (!options.paths) return undefined;
    return options.baseUrl ??
        options.pathsBasePath ||
        host.getCurrentDirectory();
}

TypeScript sets pathsBasePath to the directory of the tsconfig that defines the paths key. In a monorepo this is the repo root (where tsconfig.base.json lives), not the app directory.

TypeScript therefore resolves "../../libs/shared-lib/src/*" relative to the repo root:

path.join('/repo-root', '../../libs/shared-lib/src/foo')
// → '/libs/shared-lib/src/foo'   ← does not exist

Why webpack/Turbopack works but TypeScript does not: load-jsconfig.js uses path.dirname(tsConfigPath) (the app dir) as the implicit baseUrl fallback when baseUrl is absent. JsConfigPathsPlugin resolves the rewritten ../../... paths relative to the app dir, which is correct. The TypeScript checker goes through the same getTypeScriptConfiguration call but uses pathsBasePath instead, which points at the wrong base directory.

Proposed fix

After deleting baseUrl, set pathsBasePath to path.dirname(tsConfigPath) so TypeScript uses the same resolution base as webpack:

result.options.paths = rewritePathAliasesWithoutBaseUrl(normalizedBaseUrl, result.options.paths);
delete result.options.baseUrl;
result.options.pathsBasePath = path.dirname(tsConfigPath); // ← add this

This ensures the rewritten ../../libs/... paths are resolved from the app's tsconfig directory, producing the correct absolute path regardless of where in the extends chain paths were originally defined.

Workaround

None that avoids modifying node_modules. Pinning to Next.js 16.1.0 is not viable because that version predates the TypeScript 6 compatibility code entirely — TypeScript 6 rejects baseUrl as deprecated before Next.js can influence resolution. The getTypeScriptConfiguration.js compat code in 16.2.x is the correct approach; it is just missing the one-line pathsBasePath update.

[eps1lon]

Does that still reproduce with next@canary. This was supposed to be fixed with #92277

[gardsa]

Still reproduces on 16.3.0-canary.5 - #92277 fixed the webpack side but not the TypeScript checker side. Looks like #93356 has the right fix 👍

[eps1lon]

If you want to use deprecated compilerOptions, you have to set ignoreDeprecations: "6.0". We'll support that with #93377. We won't support handling deprecated compilerOptions without ignoreDeprecations.

[gardsa]

If you want to use deprecated compilerOptions, you have to set ignoreDeprecations: "6.0". We'll support that with #93377. We won't support handling deprecated compilerOptions without ignoreDeprecations.

Tested with "ignoreDeprecations": "6.0" set in tsconfig.base.json - still reproduces on 16.3.0-canary.5 with the same error.

The bug is independent of the deprecation warning. getTypeScriptConfiguration.js triggers the TS6 compat path rewriting on TypeScript version alone (semver.gte(typescript.version, '6.0.0')), not on whether baseUrl is flagged as deprecated. It rewrites paths to be relative to the app dir and deletes baseUrl, but never sets pathsBasePath. TypeScript then resolves the rewritten ../../libs/... paths from the repo root (where pathsBasePath points, since that's where tsconfig.base.json defines paths), walks above it, and finds nothing.

ignoreDeprecations: "6.0" / #93377 won't address this - the rewrite still runs and pathsBasePath is still not updated. The fix in #93356 is what covers this case.

[ellingtontrevor642-art]

Good suggestion I will incorporate it

…

On Thu, Apr 30, 2026, 11:35 AM Sam Gard ***@***.***> wrote: *gardsa* left a comment (vercel/next.js#93336) <#93336 (comment)> If you want to use deprecated compilerOptions, you have to set ignoreDeprecations: "6.0". We'll support that with #93377 <#93377>. We won't support handling deprecated compilerOptions without ignoreDeprecations. Tested with "ignoreDeprecations": "6.0" set in tsconfig.base.json - still reproduces on 16.3.0-canary.5 with the same error. The bug is independent of the deprecation warning. getTypeScriptConfiguration.js triggers the TS6 compat path rewriting on TypeScript version alone (semver.gte(typescript.version, '6.0.0')), not on whether baseUrl is flagged as deprecated. It rewrites paths to be relative to the app dir and deletes baseUrl, but never sets pathsBasePath. TypeScript then resolves the rewritten ../../libs/... paths from the repo root (where pathsBasePath points, since that's where tsconfig.base.json defines paths), walks above it, and finds nothing. ignoreDeprecations: "6.0" / #93377 <#93377> won't address this - the rewrite still runs and pathsBasePath is still not updated. The fix in #93356 <#93356> is what covers this case. — Reply to this email directly, view it on GitHub <#93336 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/B7ZV7SXXFUTPNISUACDPCC34YN6E5AVCNFSM6AAAAACYKB4W52VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHM2DGNJUGMYDONRZGY> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[prodkt]

Confirmed, bug still exists in current canary for this moment in time 16.3.0-canary.9.

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.