In this PR, we allow certain compiler options to be configured via comments within a file for the scope of that file. This means you can write, for example:

Fixes #31035

I've wanted to look into this since I originally added the generic pragma-parsing infrastructure for @ts-check and related comments.

To start, I'm aiming to allow every compiler option in the "Strictness" category as a per-file configurable option. That way you can toss a // @ts-strict into a (potentially javascript) file and get strict mode checking in it. Currently in this PR, every option in that category is supported except for strictNullChecks and exactOptionalPropertyTypes - they do some global type-identity configuration that's taking me a bit longer to abstract away into a per-file configuration. (Also strictNullChecks just straight up is referenced more than any other compiler option.)

To start off the discussion, in the linked issue, @RyanCavanaugh asked:

It's not really even clear what this means - if you have a type declared in file A, another type in file B, and you try to relate them in file C, whose value of strictFunctionTypes is in play?

Currently in this PR, whichever is stricter. If either file the types originated from has it set, it's related strictly. Could go the other way and relate loosely if either is explicitly non-strict if looser checking is more preferable. Honestly, most of these "which context controls the flag" already have fairly canonical answers, either because we already look up a context to check JS-y-ness (for JS-file-specific-behaviors or error ignoring), or to issue an error in (in which case the error node location is a pretty logical context).

Anyways, I'm hoping this implementation can jumpstart discussion on the value of in-file pragmas for compiler options, specifically with the goal of bikeshedding the syntax and what options we should ultimately expose on a per-file basis. (Technically, I've tried to make the internal APIs for adding new per-file pragmas very type-safe and very easy to use.)

TODO list:

• File-local support for strictNullChecks (Per file option: strictNullChecks #50347 for separate review comments, since it's big)
• File-local support for exactOptionalPropertyTypes
• Errors on conflicting file-local options/redeclarations (silently uses the last declaration and silently discards invalid arguments right now)
• Copious testing (thus far I've just been prototyping in a sample project)