[tsc] Inform user when detected tsconfig.json file is not being applied

[jednano]

Under the following conditions...

1. The tsc command is run directly on files, instead of a project.
2. A tsconfig.json file is detected.

I'm requesting that the user be informed the detected tsconfig.json file is not being read, because the project is not being compiled. I'm not sure the best language for this message, but I'm envisioning something to this effect...

$ tsc foo.ts
[INFO] Detected tsconfig.json file, but it's not being applied, because you are targeting
individual files and not a project.
foo.ts(1,25): error TS1148: Cannot compile modules unless the '--module' flag is provided.

This would prevent issues like #6591, which I was having before.

[DanielRosenwasser]

#6600 might be the way to fixing this.

[jednano]

But in my case, there is no error with my tsconfig.json file. It's just not being read or used because I'm compiling an individual file, so I'm not sure how #6600 has anything to do with this.

[mhegazy]

this will be a breaking change, since existing projects today can have tsconfig but not use that in build.

[aredfox]

but maybe at least give a warning from the compiler log which tsconfig is being applied, is there a flag?

[ghost]

Would have saved me a few hours if this message had been implemented.

As it stands I tried every possible combination of changes to tsconfig.json to make it work, only to eventually find out that tsconfig.json was being ignored because I am specifying the file to be compiled on the command line, which is really unexpected behaviour - "ah, you're specifying your input file? I see, well just to punish you for that, no tsconfig.json for you ha ha!"

[jednano]

@mhegazy this won't be a breaking change if we limit the fix to just informing the user which tsconfig file is being applied, as @aredfox suggested. Can we go that route at the very least? I'm not sure how a message would be a breaking change. It doesn't have to be an error or even a warning. Just inform us what's being applied, right?

[RyanCavanaugh]

Some people consider console output to be a breaking change #24123 (we don't)

It's a legitimate problem from the API perspective though; a build chain might reasonably be invoking tsc with an explicit list of files (we do this despite having tsconfig files, because our build setup is ancient) and interpret any output at all from the compiler to be an error state that should block the build.

[cloverich]

I wonder if a verbose flag could be added to have it output this kind of information to keep it from being backwards incompatible? It could perhaps output the compiler options being used, and where it found the information.

To add an example on how this can confuse users now: I was specifying the input file via cli arg, and my build was failing. The error asked me to specify a compiler option (Try changing the lib compiler option to es2015 or later). This was already specified in my tsconfig.json, so I assumed I had a syntax or filename error in my tsconfig, or just did not understand how the option worked. I think i would have been lost quite a while if I didn't find this github issue!

[silvenon]

As a TypeScript beginner this behavior really threw me off. It seems to be mentioned in only a single paragraph in tsconfig.json docs:

When input files are specified on the command line, tsconfig.json files are ignored.

This paragraph is not distinctive in any way so it's really easy to miss. It would be very helpful if that was emphasized somehow and if this info was added to tsc --help as well.

I'm sure there are many non-breaking things that can be done to make people aware of this usually unexpected behavior.

Btw, is there a way to run tsc on a certain file with tsconfig.json?

[Download]

So I just found out that I have been using tsc with a tsconfig that was being ignored for days already. This is really unexpected behavior afaic and it would help a lot if it would print just a bit of log output saying something like:

Detected tsconfig.json, but ignoring it because input files were specified on the commandline.
SEE https://www.typescriptlang.org/docs/handbook/tsconfig-json.html#ignored

[Download]

a build chain might reasonably be invoking tsc with an explicit list of files (we do this despite having tsconfig files, because our build setup is ancient) and interpret any output at all from the compiler to be an error state that should block the build.

If you interpret any output at all as an error, you will get false positives on errors, right? Who is to blame there?
Also, isn't there stdout and stderr exactly for this reason?
Just so you know, this behavior of ignoring tsconfig.json is unexpected to me and I have some experience in Javascript toolchains. I cannot name another tool that does this. Also, not being given any warning about it ignoring the config file is also unexpected.

[RyanCavanaugh]

This seems to surprise about one person every six months, the risk of breaking build chains is definitely nonzero, we'd need to provide some new way to opt out of the warning, and it's clearly described in the documentation. so this isn't meeting the bar.

[Download]

This seems to surprise about one person every six months,

I think that's a pretty bold claim. Let me translate: we get one issue report every 6 months.

I think you will find that for every person actually taking the trouble to report an issue there are hundreds that were equally surprised but just didn't report it. Also I think if an issue gets reported over and over (even if 'just' once every 6 months) that's a pretty strong indication that something is amiss. But yeah if printing a warning is too risky I guess there are not much options left...

[Download]

it's clearly described in the documentation.

Where? Are you talking about

It seems to be mentioned in only a single paragraph in tsconfig.json docs:

When input files are specified on the command line, tsconfig.json files are ignored.

It's a single sentence that we cannot even link to because it has no header. I think calling it clear is a bit optimistic.

[silvenon]

Yep, I found it only because I was specifically looking for it.