Deprecate, remove support for baseUrl

Today, baseUrl performs two functions:

it acts as a prefix for all entries in paths
it acts as a potential resolution point for all bare paths

But almost nobody realizes that last part. It means if you have the following:

{
  "compilerOptions": {
    // ...
    "baseUrl": "./src",
    "paths": {
      "@app/*": ["app/*"],
      "@lib/*": ["lib/*"]
    }
  }
}

An import like

import * as blah from "blah.js";

might resolve to ./src/blah.js.

Usually, developers who wrote this only intended to re-map any modules that started with @app/ and @lib/. Unfortunately people specify a baseUrl because it was previously required to make paths work or as a prefix.

In TypeScript 7.0, we are not reimplementing baseUrl.
Instead, paths will need to manually specify a custom prefix.

  {
    "compilerOptions": {
      // ...
-     "baseUrl": "./src",
      "paths": {
-       "@app/*": ["app/*"],
-       "@lib/*": ["lib/*"]
+       "@app/*": ["./src/app/*"],
+       "@lib/*": ["./src/lib/*"]
      }
    }
  }

In the event that you want to maintain the same behavior as before, you can add an additional path mapping for the baseUrl itself:

{
  "compilerOptions": {
    // ...
    "paths": {
      // A new catch-all that replaces the baseUrl:
      "*": ["./src/*"],

      // Every other path now has an explicit common prefix:
      "@app/*": ["./src/app/*"],
      "@lib/*": ["./src/lib/*"],
    }
  }
}

In TypeScript 6.0, we will be deprecating this behavior. Using baseUrl will lead to an error which can only be resolved by applying one of the above fixes, or using --ignoreDeprecations.

 // A new catch-all that replaces the baseUrl:
 "*": ["./src/*"],

I have tried this in mui/base-ui#2969, but it didn't work.

I could only find two things that work with TypeScript 5.9.3 (latest stable):

Fix the path to something that seems absurd:

--- a/tsconfig.base.json
+++ b/tsconfig.base.json
@@ -14,11 +14,11 @@
     "skipLibCheck": true,
-    "baseUrl": "./",
     "allowImportingTsExtensions": true,
     "paths": {
-      "@base-ui-components/react/*": ["./packages/react/src/*"],
-      "@base-ui-components/react": ["./packages/react/src"],
-      "@base-ui-components/utils/*": ["./packages/utils/src/*"],
-      "docs/*": ["./docs/*"]
+      "@base-ui-components/react/*": ["../packages/react/src/*"],
+      "@base-ui-components/react": ["../packages/react/src"],
+      "@base-ui-components/utils/*": ["../packages/utils/src/*"],
+      "docs/*": ["../docs/*"]
     }
   },

Duplicate the path values, between the base config and the extended config. It's the state the PR is in [internal] Remove deprecated baseUrl TypeScript option mui/base-ui#2969.

Both are weird. Per what https://www.typescriptlang.org/tsconfig/#extends describes, the extends should duplicate the paths values, and resolve the path relative to the extends file.

All relative paths found in the configuration file will be resolved relative to the configuration file they originated in.

But it's not what happens. It looks like a bug in TypeScript extends behavior.

Olivier Tassinari (@oliviertassinari)

Olivier Tassinari (@oliviertassinari) do you mean a bug in TS 6 (our usual nightlies?) or @typescript/native-preview or both?

I was expecting to be able to remove baseUrl on typescript@5.9.3.

extends does not merge paths values. They are always fully overridden.

Andrew Branch (@andrewbranch)

extends does not merge paths values. They are always fully overridden.

Andrew Branch (@andrewbranch) Yeah, this part seems all good. I didn't observe a problem with the merge behavior of extends with paths.
The issue is with the paths resolution.

Sorry, this stuff is super confusing to talk about. The expected behavior is that in whatever file you actually define paths, the relative paths are always resolved to that file. In the past, it was possible for a base config to define paths, and many extending configs to define baseUrl, which would cause the single paths definition to effectively be reinterpreted against a different baseUrl for every project. That was never really an intentionally designed feature, just a consequence of the natural interaction between two features. We don’t expect many people were doing that on purpose, but if you were, you will end up defining paths in more config locations than before. https://github.com/andrewbranch/ts5to6 should be able to handle that migration automatically.

fix(api): deprecated baseUrl usage

When I try the catch-all solution by adding "*": ["./*"] to my paths, VSCode will start auto-suggesting imports from node_modules which is incorrect. Is anyone else facing this issue?

Remove baseUrl from all tsconfig files ahead of TS 6.0 deprecation

fix: remove deprecated baseUrl

When I try the catch-all solution by adding "*": ["./*"] to my paths, VSCode will start auto-suggesting imports from node_modules which is incorrect. Is anyone else facing this issue?

Yeah, same problem here, all autoimports start with node_modules/ instead of the name of the library

When I try the catch-all solution by adding "*": ["./*"] to my paths, VSCode will start auto-suggesting imports from node_modules which is incorrect. Is anyone else facing this issue?

Yes. Does anyone have the workaround?

When I try the catch-all solution by adding "*": ["./*"] to my paths, VSCode will start auto-suggesting imports from node_modules which is incorrect. Is anyone else facing this issue?

Yeah, same problem here, all autoimports start with node_modules/ instead of the name of the library

Please post a new issue with a repro so that we can investigate.

Changed tsconfig.json to fix deprecation warning for `baseUrl`, see m…

I have not seen anyone mention this error with 5.9.3:

> nx run shared-webviews:build

Compiling TypeScript files for project "shared-webviews"...
error TS5090: Non-relative paths are not allowed when 'baseUrl' is not set. Did you forget a leading './'?
/Users/edoardo.luppi/IdeaProjects/client-vscode/client-shared/webviews/src/lib/webviews.ts:7:35 - error TS2307: Cannot find module '@hcl/shared/ts' or its corresponding type declarations.

7 import type { WithOptional } from "@hcl/shared/ts";
                                    ~~~~~~~~~~~~~~~~

Is this supposed to be resolved in 6.x? My current paths are like the following:

"paths": {
  ...
  "@hcl/shared/file-manager": ["./client-shared/file-manager/src/index.ts"],
  "@hcl/shared/utils": ["./client-shared/utils/src/index.ts"],
  "@hcl/shared/webviews": ["./client-shared/webviews/src/index.ts"],
  ...
}

Edit: if this is considered a supported use case for TS, this might be caused by Nx.

Merge/develop into admin-ui/main (#1828)

chores: 解决ts警告 (#566)

fix: remove `baseUrl` from TypeScript configuration

fix(backend): Remove deprecated baseUrl option from tsconfig

fix(api): deprecated baseUrl usage

test(deps): keep the typescript hold while either blocker stands

chore(deps): hold typescript 7 and openai 3 back with a guarded ignore (

Navigation Menu

Repository navigation

Deprecate, remove support for `baseUrl` #62207

15 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Deprecate, remove support for baseUrl #62207

Description

Activity

oliviertassinari commented on Oct 11, 2025

DanielRosenwasser commented on Oct 12, 2025

oliviertassinari commented on Oct 12, 2025

andrewbranch commented on Oct 13, 2025

oliviertassinari commented on Oct 13, 2025

andrewbranch commented on Oct 13, 2025

15 remaining items

Jasper-Nelligan commented on Apr 10, 2026

ruizmarc commented on Apr 21, 2026

li-zck commented on Apr 22, 2026

RyanCavanaugh commented on Apr 22, 2026

lppedd commented on May 17, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

Deprecate, remove support for `baseUrl` #62207