tsconfig baseURL being used to resolve relative paths

[BenGladman]

This is a recent regression (running esbuild 19)

Minimal reproduction case: https://github.com/BenGladman/esbuild-baseurl-issue

In the reproduction I'm importing from ../hello, and this should pick up the hello.ts file in the module's parent directory. But when bundling with esbuild, it is in fact importing hello.json, which is the file relative to the baseURL.

tsc does not do this. And according to the docs, baseURL should only be used to resolve non-relative imports.

[pfumagalli]

Seconded, I'm also seeing the same behavior. In the simplest case I could find I have:

tsconfig.json

{
  "compilerOptions": {
    "baseUrl": "./subdir"
  }
}

test.ts

export const foo = "well, this is correct...";

subdir/test.ts

export const foo = "WRONG";

When running with 0.19.0:

$ esbuild --version
0.19.0
$ esbuild test.ts 
export const foo = "WRONG";
$

When running with 0.18.20

$ esbuild --version
0.18.20
$ esbuild test.ts 
export const foo = "well, this is correct...";
$

When running with the standard tsc:

$ tsc --version
Version 5.1.6
$ tsc --target esnext
$ cat ./test.js
export const foo = "well, this is correct...";
$

[BenGladman]

Simplest fix for me is to remove the baseURL from tsconfig, which is a bit of a relic anyway. But that mightn't be possible for everyone

[pfumagalli]

Oh! @BenGladman you're right... I am using baseUrl because in a monorepo my tsconfig.json I had a paths statement looking like:

{
  "baseUrl": "./",
  "paths": {
    "otherpackage": [ "workspaces/otherpackage/src" ],
    "otherpackage/*": [ "workspaces/otherpackage/src/*" ]
  }
}

Removing it makes both tsc and esbuild complain (they say workspaces/... is not relative even if it actually is) but replacing the whole thing with:

{
  "paths": {
    "otherpackage": [ "./workspaces/otherpackage/src" ],
    "otherpackage/*": [ "./workspaces/otherpackage/src/*" ]
  }
}

and basically prefixing every path definition with ./ makes it go away and everything works like a charm!

Thanks!

[evanw]

Thanks for the report. I suspect this broke when I attempted to fix #3238 (moving tsconfig.json checks before --package=external checks). Unfortunately I don't currently have test coverage for this edge case.