Before You File a Proposal Please Confirm You Have Done The Following...

• I havesearched for related issues and found none that match my proposal.
• I have searched thecurrent rule list and found no rules that match my proposal.
• I haveread the FAQ and my problem is not listed.

Relevant Package

typescript-estree

My proposal is suitable for this project

• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

Splitting out of#7435: that issue indicates that the error message for trying to generate type information for a file not recognized by thetsconfig.json is not ideal. But as we see in#7752, if we don't check to make sure that the file is recognized... type information still works! This issue tracks: can we allow "unknown" (not included in the TSConfig) files to have type info generated by the project service?

Not needing to explicitly include files in the TSConfig would be ideal from the perspective of simple configs. It'd mean we can get rid oftsconfig.eslint.json-style strategies of having a different TSConfig for your linted code. Those are commonly used to enableallowJs for root-level config files (e.g.eslint.config.js) not included in the project's TS-onlytsconfig.json.

We can't enable that kind of "config-less typed JS linting" with traditionalproject: true styles of approaches because of the following combination of tech restrictions:

1. Thedefault program in TypeScript is a "builder": each time you add a new file to it, it recreates & recomputes a large swathe of nodes and types.
   • See alsoEnhancement: Allow specifying default TSConfig behavior with project service #7761 (comment) for points on misconfiguration.
2. ESLint does not provide us with APIs around when files are added, updated, or removed. We're restricted to just setting everything up once in the parser. Seefeat: parsing session objects eslint/rfcs#102.
3. As a result, what was renamed toDEPRECATED__createDefaultProgram in v6 is known to cause significant slowdowns in non-trivial uses

If we can use the project service in a way that doesn't suffer from the same drawback, then that'd be a massive win for users.

Additional Info

Shoutout+thanks as always@jakebailey for helping us with the TypeScript side!