Allow tsconfig.json when input files are specified

[brapifra]

I don't know why the tsconfig.json is ignored even when the --project or -p option is specified.
In my opinion, the right implementation should be:

• If no --project or -p option: Ignore tsconfig.json
• Otherwise: Use the configuration file specified. All the options used in the command line should overwrite the ones of the configuration file. E.g. The include/exclude keys of the tsconfig.json will be ignored when input files are specified.

[ghost]

I don't know why the tsconfig.json is ignored even when the --project or -p option is specified.

Could you provide a repro for a situation where tsconfig is ignored?

[brapifra]

Sure @andy-ms , but I mean, this is not even a bug. This behaviour is explicitly explained in the docs: When input files are specified on the command line, tsconfig.json files are ignored.

When you do tsc file.ts -p tsconfig.json you get:

The lines of code are pretty easy to find

I just can't understand why it's implemented this way.

[ghost]

Probably because no one's implemented it -- could you explain what the use cases are?

[brapifra]

A pretty common practice is to have a pre-commit hook to compile only the staged files in your git project (It makes no sense to compile all the project).
If you try to create this hook that runs tsc over each staged file, you won't be able to use the tsconfig.json, as you are specifying some input files. @andy-ms

[jescalan]

I have another use case for this. We have many projects that use typescript, and would like to reduce boilerplate and keep our typescript config in one place, so it can be uniformly applied across all our projects for consistency.

At the moment, there isn't a way to do this, since you can't specify both a glob of files to check, and an external path to a tsconfig.json file. The only workaround in the meantime is to copy/paste a tsconfig.json file into the root of every project and have it only contain an "extends" statement. This isn't the end of the world, but it's more boilerplate than we want - the fewer duplicate files across multiple projects we can have, the better.

This same goal is easily accomplished with TSLint, by using their --config option as well as a glob of files to lint. Is there any specific reason why it is disallowed by typescript itself? If not, I would be happy to take a stab at implementing it via pull request, just want to make sure its ok with maintainers.

[zpdDG4gta8XKpMCd]

related, but never considered #12958

[JasonKaz]

I have a different use case that needs this as well. We have a pre-commit hook that does a quick type check (tsc -p tsconfig.json --noEmit). Currently it checks all the files specified in tsconfig.json, but it would be nice to only type check the files that were modified. We are currently using lint-staged to run linting tools on modified files, it would be great to only run the type check on the modified files too.

Like @brapifra said here, #27379 (comment), it's written in the docs that this should be possible, but it clearly isn't.

[RyanCavanaugh]

ref #22649, #13575

[RyanCavanaugh]

We have some questions for everyone in this thread

Long story short, the real problem we see is that people make a tsconfig.json, then run

tsc someFile.ts

and get garbage confusing errors because e.g. their tsconfig specifies target: ESNext and the error says something like "This is an ES5+ only API, change your target!". So we'd like to change that so that tsc always picks up a nearby tsconfig file, and provide an opt-out like --ignore-tsconfig for people who want to ignore it intentionally.

However, we're not sure what tsc someFile.ts means if there's a tsconfig present:

Question 1, do we:

• Overwrite the files setting
• Append to the files setting
• Prepend to the files setting (order rarely matters but sometimes does...)

Question 2:

• Are include and exclude still in play if there are some files specified on the commandline?

Question 3:

• What if someFile.ts was in the exclude list?

Thoughts?

[fatcerberus]

Just my two cents:

A pretty common practice is to have a pre-commit hook to compile only the staged files in your git project (It makes no sense to compile all the project).

This use case seems problematic in general, since (AFAIK) TS needs to see your whole project for some things to work (e.g. const enum, declaration merging), unless you use isolatedModules which disables those features.

[timocov]

Question 1.

I would expect that we'll "Overwrite the files setting".

Question 3.

If we'll treat someFile.ts as file to override files list, then no problem here - from the docs:

Files included using "include" can be filtered using the "exclude" property. However, files included explicitly using the "files" property are always included regardless of "exclude".

Question 2.

IMO include should be ignored in this case.

I think there is cases when some modules pollute global scope and it might break the compilation (because not all modules require that modules with globals even if they use them), but I believe developers should import deps explicitly (via triple-slash directives or even import statements in this case).

[timocov]

So we'd like to change that so that tsc always picks up a nearby tsconfig file, and provide an opt-out like --ignore-tsconfig for people who want to ignore it intentionally.

@RyanCavanaugh So, we will not be able to pass path to the custom tsconfig via --project CLI option, right? I believe it's a use case as well and it would be good to cover it too.

[GermanJablo]

How does VS Code generate red underline for TypeScript issues on individual files?

I think it doesn't compile files individually. You just see those lines after Typescript has processed the entire codebase

[lveillard]

Same as others, this breaks my lint-staged configuration and took me hours to find out why.

I understand the ambiguity of tsc someFile.ts with a tsconfig file, i would maybe add just a flag for the most common use case which seems to be: run it as you run the folder and it was just an individual file)

Also two less ambiguous options:
A) a -skipConfig or -skipProject or -force could force it against the tsconfig
B) a flag to use the tsconfig on purpose, like just `tsc someFile.ts ../..tsconfig.json

I would probably do B so it would cause no regressions. Also that's the hallucinated solution that ChatGPT gives when asking why the tsconfig is not working and how to force it.

[lveillard]

Btw this is a cool workaround: https://github.com/gustavopch/tsc-files

[alveifbklsiu259]

Hi everyone,

I’ve encountered the same issue discussed here and wanted to share a solution I’ve been working on. I created a project called tscw-config that addresses this problem. It allows users to run tsc with both files and tsconfig.json at the same time:

• It provides CLI and API that you can use.
• It seamlessly integrates with most popular package managers, including:
  • npm
  • pnpm
  • Yarn
  • Yarn (Plug’n’Play)
• It is well tested.

Feel free to check it out and let me know if you have any feedback or suggestions!