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

This is a follow-up to#6172 and the TypeScript / ESLint meeting we had last week.

Currently, type-aware mode usests.Program to do its work. There are some problems with this approach:

• This mode is not references aware, leading to the need to either put every file into one program, or manually specify all programs (https://typescript-eslint.io/linting/typed-linting/monorepos).
• With multiple programs in play, lots of work can be duplicated as projects can reference each other.
• This project has to manage much of the lifecycle of Programs, and do a lot of patching to the program to make things work (e.g. not emit, make sure not to exit, etc). This seems to lead to known memory leaks and other problems.
• Probably more I'm forgetting. I don't think I need list more 😄

#6172 takes the approach of using the LanguageService to handle this stuff. This is a good step, and one taken by projects like ts-morph. However, a single LanguageService itself will only handle one project at a time, so is only a partial fix.

My idea is to go further, and usetsserverlibrary'sProjectService instead. This is "the thing" that tsserver uses to load projects and respond to language server requests for the editor. The idea is that you can create a LanguageService, then act like a user does, opening files, making requests, closing files, and so on. This means:

• Project references are handled "for free".
• Users do not need to specifyany tsconfig, just like how you don't specify anything when opening VS Code.
• The lifecycle of programs and related language serivces is fully managed, hopefully fixing leaks.
• Workshouldn't be duplicated, or at least not duplicated any more than anyone already experiences using TypeScript in their editors.

The general approach is as follows:

• Importtsserverlibrary instead oftypescript.
• Create aProjectService. Like everything else, it takes in a host, but nothing surprising.
• To look at a file, callopenClientFile to mark the file as open (potentially providing contents), and then callgetScriptInfo on its path.
• Drill down fromScriptInfo likegetScriptInfo(filename).getDefaultProject().getLanguageService(/*ensureSynchronized*/ true) and so on until you get to Program / TypeChecker whatever else is needed.
• Eventually, close the file.

There are some problems:

• tsserverlibrary is an entirely different module thantypescript. Will this break downstream rules which importtypescript directly? Is that a thing people do? Do we have to move the API?(uh oh)
• In CLI mode, this all seems fine, as the service does all of the work. But in the editor, is this too heavy giventsserver is already running? maybe it's not a problem becuase it's no worse than now.
• If people are running one of the "parallel eslint" wrappers, will this cause resource usage problems? Or, again, is this no worse than the current state of things?

Fail

N/A

Pass

N/A

Additional Info

No response