Feature Request: LanguageServiceHost plugin

Search Terms

language service host compiler plugin

Refs #16607

Suggestion

Currently, TypeScript only supports proxying the language service. It would be good to have an officially supported way of being able to proxy the LanguageServiceHost as well.

Use Cases

Being able to provide a plugin that changes how the language service host behaves is often a requirement for use cases where the default behaviour of TypeScript in Visual Studio Code does not mirror the compile time behaviour when using tools that implement a language service host with TypeScript.

For example in Deno, we utilise full path names for modules, including TypeScript ones. The standard language service host disallows this (because it assumes that the module name won't end in .ts at runtime).

There are likely to be other use cases where the behaviour of the language service host differs when using other forms of TypeScript other than tsc and Visual Studio Code, where it would be useful to allow plugins to mimic that behaviour, in particular in Visual Studio Code, so that the editing experience can be more rich.

Examples

I currently have a plugin which just monkey patches the LanguageServiceHost to inject similar logic for module resolution to what is done in Deno. This is because I cannot return a proxy, like I could with the LanaguageService.

Checklist

My suggestion meets these guidelines:

• This wouldn't be a breaking change in existing TypeScript/JavaScript code
• This wouldn't change the runtime behavior of existing JavaScript code
• This could be implemented without emitting different JS based on the types of the expressions
• This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• This feature would agree with the rest of TypeScript's Design Goals.

Inizia dalla guida «Writing a Language-Service-Plugin» a cui fa riferimento l'issue e analizza l'index.ts del plugin di esempio. Confronta l'approccio esistente del proxy LanguageService con il caso d'uso richiesto per l'utilizzo di un proxy LanguageServiceHost, inclusa la risoluzione dei moduli in stile Deno. Il lavoro dovrebbe considerarsi concluso quando sarà definito un percorso per le estensioni supportate che eviti il monkey-patching.