Always look for tsconfig, allow command line to override tsconfig file list

[weswigham]

This allows you to say, eg, tsc -p path/to/tsconfig.json --other-option-override false glob/*/filename-override.ts - essentially allowing you to use config extension on the commandline, including overriding included files. Even when -p isn't provided (but other options or filenames are), we also now look up a tsconfig.json in the current directory to use as the base config for the invocation (which is theoretically a breaking change, since we'd previously ignore the tsconfig, but it looks like that occasionally confused people, looking at the linked issue).

Fixes #27379

[fatcerberus]

we'd previously ignore the tsconfig, but it looks like that occasionally confused people

More than just occasionally, if the number of times I've had to explain this behavior to people on Discord is any indication.

[weswigham]

We discussed this at today's design meeting. One work item is adding the ability to set a command line option to null on the command line (just like you can in a tsconfig already) to explicitly unset an option - primarily so you can pass -p null as a uniform way to ignore a folder's existing tsconfig and get today's "ignore the tsconfig" behavior without needing to make a new empty tsconfig yourself. Another worry/concern is that incremental may not invalidate the cache on root files list change right now if that file list doesn't come from a tsconfig, so a command sequence like

tsc --incremental --tsBuildInfoFile .tsbuildinfo --strict file1.ts file2.ts
tsc --incremental --tsBuildInfoFile .tsbuildinfo --strict file1.ts

(which we allow today already) might not have correct incremental results and may incorrectly reuse the incremental data from the earlier build despite the file list changing, so is also a related issue worth looking in to, since using the folder's tsconfig by default, rather than ignoring it, may result in many more command line invocations having incremental set with arbitrary file lists.

As for scheduling, we may do this for 4.9 or if not for 5.0.

[weswigham]

Oh, neat, we already supported --strict null and the like, just not -p null. Neat. Small change to add it.

[weswigham]

And as for the concern about buildinfos, I put together a harness that could actually test multiple consecutive invocations - looks like we handle the file list changing entirely just dandy. So I'd call this done and ready for review.

[sheetalkamat]

And as for the concern about buildinfos, I put together a harness that could actually test multiple consecutive invocations - looks like we handle the file list changing entirely just dandy. So I'd call this done and ready for review.

We already have this framework which you can use by calling verifyTscWithEdits it takes commandline args for the edits as well.

The concerning scenario is tsc --b invocation after -p somefile.ts.. You would need to i think check for root files are matching in buildInfo vs whats provided to make program not uptodate here https://github.com/microsoft/TypeScript/blob/main/src/compiler/tsbuildPublic.ts#L1600

[gburt]

@sheetalkamat are you expressing concern that this PR and the -b CLI flag wouldn't work well together?

If there's concern about this changing the default of tsc foo.ts to load the tsconfig.json file, I think removing/punting that change from this PR would be acceptable to the > 600 people who are watching #27379 since even without that this PR would unlock the ability to do typechecking via the CLI on subsets of files without crufty solutions (like generated/temporary config files) eg for "changed files in this git branch", which would be an enormous win.