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

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read 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 the tsconfig.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 of tsconfig.eslint.json-style strategies of having a different TSConfig for your linted code. Those are commonly used to enable allowJs for root-level config files (e.g. eslint.config.js) not included in the project's TS-only tsconfig.json.

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

1. The default 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 also Enhancement: 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. See feat: parsing session objects eslint/rfcs#102.
3. As a result, what was renamed to DEPRECATED__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!