Proposal: Allow `paths` compilerOption without `baseUrl`

[mheiber]

Related issue: #28321

Search Terms

baseUrl, paths, compilerOptions

Suggestion

Do not require 'baseUrl' in compilerOptions when 'paths' is provided.

Use Cases

We want to use 'paths' for type-checking, but don't want to resolve non-module relative names:

./1.ts

import { two } from "2"

./2.ts

export const two = 3;

Examples

tsconfig

{
  "compilerOptions": {
    "paths": {
        "foo": ["../foo"]
    }
  }
}

Actual behavior of paths without baseUrl:

Error: Option 'paths' cannot be used without specifying '--baseUrl' option

Expected behavior of paths without baseUrl:

• No error message
• paths are resolved relative to the project directory (which I think means the same thing as "where the tsconfig is")

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

[robpalme]

We have a horrifying workaround that intentionally prevents resolving bare-specifiers against the "baseUrl" whilst permitting "paths" to be used.

It involves setting an impossible directory as "baseUrl" and then prepending "paths" values with "../" to jump out of the impossible directory back up to the project root.

{
  "compilerOptions": {
    "baseUrl": "\u0000",
    "paths": {
        "foo": ["../../foo"]
    }
  }
}

... which works today and achieves the same thing as the proposed example ...

{
  "compilerOptions": {
    "paths": {
        "foo": ["../foo"]
    }
  }
}

It would be great to be able to drop this workaround.

[RyanCavanaugh]

I'm pretty confused about what's going on here (since there is no file named "foo"). Can you provide some more examples of what you'd want this to do? What is the proposed difference between what you want and just setting baseUrl to the "project root" yourself?

[mheiber]

Thanks for taking a look @RyanCavanaugh

I'm pretty confused about what's going on here (since there is no file named "foo")

The presence of a "foo" file is not intended to be relevant to this example. We mentioned it to show that specifying compilerOptions.paths forces also specifying baseUrl.

What is the proposed difference between what you want and just setting baseUrl to the "project root" yourself

When we set baseUrl, the semantics of TS non-relative imports changes in a way that conflicts with ECMAScript semantics. We're hoping to avoid this behavior. There's a complete example below.

Desired behavior:

tsconfig:

{
  "compilerOptions": {
    "paths": {
        "foo": ["../foo"]
    }
  }
}

file systen:

• foo.ts
  • proj
    • tsconfig.json
    • 1.ts
    • 2.ts

1.ts should error:

import two from "2"; // Error: Cannot find module '2'

2.ts contents (not relevant):

export default 2;

Actual behavior when setting paths without baseUrl

all files are as described above ^^

TS Errors:

Error: Options 'paths' cannot be specified without specifying '--baseUrl' option

Actual behavior when setting baseUrl to project root manually

tsconfig.json:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
        "foo": ["../foo"]
    }
  }
}

all other files are as described above ^^

Adding baseUrl changes the semantics of imports. Spefically, there is no longer an error in 1.ts after this change:

import two from "2"; // no error, but we want 'Cannot find module '2', which is the behavior when 'baseUrl' is not specified

TLDR: We're hoping to be able to use 'paths' without changing how all non-relative module paths are resolved

[russelldavis]

To give a more concrete example of why fixing this is important: setting baseUrl means that every new file you add to the baseUrl location (usually ., the project root) is an opportunity to accidentally break things.

For example: your code might be doing import * as ts from 'typescript', successfully importing from node_modules/typescript. You later create a file called typescript.ts at the project root for some testing. Whoops, your existing imports of typescript are now broken.

It's ideal if the only things that can override node_modules are explicit and minimal; using paths without baseUrl is the way to do that.

[russelldavis]

In the meanwhile, I discovered another workaround:

{
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
        "foo": ["../foo"],
        "*": ["__INVALID__/*"]
    }
  }
}

The other workaround caused some problems for me with Webstorm (and I think other tools), which didn't like having a baseUrl pointing to a nonexistent directory. (But it inspired this one, so thanks @robpalme.)