Add plugins property on TS Server open request

[mjbvz]

Problem

VSCode allows TSServer plugin extensions to register themselves for language modes besides javascript and typescript. The angular extension for example can register the angular TSServer plugin for the ng-html language. When an ng-html file is sent to TS and the angular plugin is not active, Typescript will treat the file contents as typescript code, resulting in a number of syntax errors

Proposal

Add an optional plugins property on TSServer open requests.

interface OpenRequestArgs {
    ...,
    plugins?: string[]
}

plugins would be a list of tsserver plugin package identifiers.

On the TypeScript side, the new logic for handling the plugins property on open requests would look something like:

• If plugins is undefined, the open request behaves the same as it does currently.
• If plugins is an array, TypeScript checks to see if any of the plugins it has loaded are in the plugins.
  • When no match is found, the opened file is ignored by the TSServer
  • If a match is found, the opened file is handled by TypeScript. The plugin would be responsible for disabling the standard TS features in the file

Open Questions

What does ignoring a file mean?
What happens when plugins is provided but no match is found against the loaded plugins on the TSServer? Two options I see:

1. TS keeps the file open and VSCode continues sending update events about it, but TS never actually generate any events or fufills any requests against it.

2. TS tells VSCode that it doesn't care about this file, perhaps by returning an error from open VSCode would no longer send sync events about the file or send TS requests about it

scriptKindName
OpenRequestArgs includes an optional field scriptKindName?: ScriptKindName.

type ScriptKindName = "TS" | "JS" | "TSX" | "JSX";

Should a new kind for external files be added?

type ScriptKindName = "TS" | "JS" | "TSX" | "JSX" | "EXTERNAL";

[mjbvz]

// cc @RyanCavanaugh @DanielRosenwasser @chuckjaz

[chuckjaz]

I prefer (2) above as it is more efficient as the server is no longer involved in the file.

I have no preference for the script kind name.

[chuckjaz]

Upon further reflection I believe both should be done. That is, a naive client of tsserver should be able to continue to send requests to tsserver regarding a file that tsserver reported as ignored and all subsequent requests would return no information nor produce events.

[angelozerr]

Me I prefer (2) with my integration of angular/language-service inside Eclipse with HTML editor to avoid sending requests.

@chuckjaz @mjbvz have you an idea when this feature will be available? Is there any chance that TypeScript 2.5 could provide this feature?

[RyanCavanaugh]

@mjbvz is this being sent from VS Code (insiders build) today?

[mattbierner]

No, we currently don't send this. Does the proposed design look good? Should I go ahead and add it to the insiders build?

[mjbvz]

@RyanCavanaugh I've added this property for prototyping the change on the TS side: microsoft/vscode@c2ee613

[RyanCavanaugh]

@mjbvz looks good. I'll try this on a local build for prototyping

[angelozerr]

I'll try this on a local build for prototyping

Glad that you will work about this issue @RyanCavanaugh !

I have just one question if you implement 2)

TS tells VSCode that it doesn't care about this file, perhaps by returning an error from open VSCode would no longer send sync events about the file or send TS requests about it

If you have 2 plugins A and B where open is done in HTML file. Plugin A must be consumed in HTML file but not plugin B. So in this case open will not throw error, is that?

[chuckjaz]

@mjbvz I added a comment to microsoft/vscode@c2ee613

[gwicksted]

Probably expected since this is in the TypeScript 2.7 milestone but thought I'd mention that currently vscode 1.18.1 x64, typescript 2.6.1, with a tsconfig.json containing either an array of objects or strings ends up always sending a plugins array with a single empty string:

[Trace  - 11:55:53 AM] Event received: telemetry (0).
Data: {
    "telemetryEventName": "projectInfo",
    "payload": {
            // ...
            "compilerOptions": {
            // ...
                "plugins": [
                    ""
                ]
            },
            // ...

[cyrilletuzi]

Just to mention, as @mjbvz recommended me to, it's still a need for tools like Angular Language Service (see cyrilletuzi/vscode-typescript-angular-plugin#1).

[mickaelistria]

This is a blocker for proper adoption of angular-language-service together with https://github.com/theia-ide/typescript-language-server and downstream adopters like Eclipse IDE.
While I believe the problem is clearly stated, I'm wondering why is the .HTML file even parsed by tsserver by default? Couldn't it be ignored (ie tsserver returning empty value) unless there is an actual tsserver plugin contributing some content?
[meta: could we relabel the title to describe the issue rather than the proposal, like "TSServer erroneously processes HTML as TypeScript"? It would make things much easier to find]

[kyliau]

@mjbvz Hello! I'm currently working on porting the Angular language service to tsserver plugin, and this issue seems to be a blocker. It has been a while since the last update, so I'm trying to catch up to the current state of tsserver plugins supporting external files.

From my experimentation, it looks like the plugin is not invoked on HTML files even though it's registered for the HTML language in package.json:

"contributes": {
    "typescriptServerPlugins": [
      {
        "name": "@angular/language-service",
        "enableForWorkspaceTypeScriptVersions": true,
        "languages": [
          "html"
        ]
      }
    ]
  },

I think the semantic of this config means "invoke the Angular plugin when user opens a HTML file".
From the logs, the Angular plugin was loaded successfully and worked for templates embedded in TS files.

The plugin was not invoked on HTML files regardless whether a special language is defined for .html (I tried defining a new language & grammar for Angular templates), and this seems contrary to typescript-language-server/typescript-language-server#104 where the plugin is invoked on HTML files.

Could you please provide an overview of the current state and some pointers on how I could contribute to land this feature?

Note, the Angular plugin could not be loaded through tsconfig.json since there's no way to associate the plugin with a list of languages the way an extension could.

I tested the Angular plugin using vsce 1.62.0, vscode 1.34.0, and typescript 3.4.5
Code is here: https://github.com/kyliau/angular-vscode-extension

Thank you!

[mjbvz]

@RyanCavanaugh We should discussion what we want to do for external language support in TypeScript server. We prototyped support a while back but never committed to finalizing it and the discussions with the Angular folk sort of just faded off