Reconsider reading from multiple tsconfig.json files

[rtsao]

Some packages such as react-dnd-touch-backend publish a tsconfig.json, which is causing esbuild to log a warning because the tsconfig references a JSON file that doesn't exist.

../app/node_modules/react-dnd-touch-backend/tsconfig.json:2:13: warning: Cannot find base config file "../../../tsconfig.base.json"
  "extends": "../../../tsconfig.base.json",
             ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning

The very latest version of react-dnd-touch-backend now prevents the tsconfig.json from being included in the published package, but this raises the question of why this is even being parsed and inspected by esbuild in the first place. It's worth noting that in my case, the TypeScript loader has not been enabled and no .ts source files are being referenced.

Is this a bug? I know tsconfig.json is also used for path aliases, but I figured esbuild would care about a tsconfig.json only in the root of the project. I'm not a TypeScript expert, but as far as I can tell, it doesn't look like nested tsconfigs are supported.

[evanw]

I figured esbuild would care about a tsconfig.json only in the root of the project.

My rationale for supporting multiple tsconfig.json files is that you may want to use esbuild to bundle code across multiple TypeScript projects, each with its own tsconfig.json file. Doing this hasn't caused any issues so far other than the warnings as far as I know. I recognize that the TypeScript compiler doesn't work exactly like this. Potential solutions could be to remove this feature from esbuild (a breaking change) or to try to figure out a way to suppress these warnings. I'm also hoping that the plugin API can be extended to help address some of these things without needing to change esbuild's core (either multiple tsconfig.json files or custom per-file warning levels).

[rtsao]

I see. For scenarios that involve bundling across multiple TS projects, how do you imagine that being structured in practice?

At least for the case of one TS project directly importing another, wouldn't any imports across project boundaries potentially break tsc? For example:

projects/
├── a/
│   ├── index.ts
│   │
│   │     import b from "../b/index";
│   │     console.log(b);
│   │
│   ├── index.js
│   └── tsconfig.json
└── b/
    ├── lib/components/foo.ts
    ├── index.ts
    │
    │     import foo from "components/foo";
    │     console.log(foo);
    │     export default foo;
    │
    └── tsconfig.json

          {"compilerOptions": "paths": {
            "components/*": ["lib/components/*"]
          }}

In this case, tsc in projects/a fails because components/foo cannot be resolved.

I'm wondering if there are bundling scenarios involving multiple tsconfigs that will never break tsc. The one I can think of is a non-TS project that imports two completely separate, independent TS projects. It makes sense to me that esbuild would support this limited scenario, but otherwise supporting multiple tsconfigs (especially in a nested manner) seems problematic, especially if it deviates from tsc.

[evanw]

I have decided to suppress this warning inside node_modules directories. Leaving this open for the discussion about multiple tsconfig.json files.

[KatSick]

@evanw looks like, this warning is still present in bazel environments, since somehow

esbuild/internal/helpers/path.go

Line 5 in 025d64e

func IsInsideNodeModules(path string) bool {

does not find node_modules (probably because of bazel sym-links?)
Should I create separate issue?

[evanw]

I'm closing this in favor of #3019, which is more comprehensive and which is a discussion that includes the TypeScript team itself.