Deprecate, remove support for `baseUrl`

[DanielRosenwasser]

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 any of the following paths

• ./src/app/blah.js
• ./src/lib/blah.js
• ./src/blah.js ⚠️

That last resolution is usually undesirable. Often though, people specify a baseUrl because it was previously required to make paths work.

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.