Support "external files" provided from TypeScript LS plugins

[RyanCavanaugh]

Tracking work for supporting non-TS files for TypeScript language service plugins

PRs this blocks:
microsoft/TypeScript#15308
https://github.com/chuckjaz/angular/tree/ts_plugin_update

/cc @chuckjaz @mjbvz

[mjbvz]

My current thinking is that we add a handles section typescriptServerPlugins contribution, something like:

"contributes": {
    "typescriptServerPlugins": [
        {
            "name": "tslint-language-service",
            "handles": {
                "extensions": [
                    ".html",
                    ".ng-html"
                ],
                "modeIds": [
                    "html"
                ]
            }
        }
    ]
}

extensions is a list of file extensions while modeIds is a list of vscode language modes.

Another version of this contributions specification where the extension defines all handled languages at the top level:

"contributes": {
    "typescriptServerPlugins": {
        "plugins": [
            {
                "name": "tslint-language-service"
            }
        ],
        "handles": {
            "extensions": [
                ".html",
                ".ng-html"
            ],
            "modeIds": [
                "html"
            ]
        }
    }
}

@chuckjaz + @egamma Would this meet your needs? Any recommended changes or additions?

[chuckjaz]

Maybe language id's instead of extensions but otherwise looks good to me.

[egamma]

• Why do you need both extensions and modeIds? This should be done in terms of language Ids and not file extensions otherwise it will not work when the user customizes file associations.
• modeIds should be languageIds to be consistent with the rest of the API

[mjbvz]

Ok, here's an updated schema proposal:

"contributes": {
    "typescriptServerPlugins": [
        {
            "name": "tslint-language-service",
            "languages": [ "html" ]
        }
    ]
}

[mjbvz]

I've pushed a prototype implementation of this with 4f398ba. It uses the contribute specification described above. Here's standard TS error reporting in an html file for example:

This should be in the next insiders build

I'll keep iterating on this on our side to improve the UX and to better handle some edge cases. Please try it out and let me know if you run into any issues

[chuckjaz]

I validated this works.

I built a version of vscode from sources following the instructions in https://github.com/Microsoft/vscode/wiki/How-to-Contribute#build-and-run-from-source synced to synced to c15e2b0.

I build a version of TypeScript that includes microsoft/TypeScript#15308 rebased to 7473dcc0410f9865295daeb9bc534f7efdbcb290.

I created a vscode extension that declares @angular/language-service as a TypeScript plugin as described above.

I verified that request from html files are directed to tsserver and that the @angular/language-service is processing the request.

[mjbvz]

Thanks @chuckjaz

One big problem with the current VSCode implementation is that if an extension registers the html language, this causes TypeScript to start reporting errors and providing intellisense in every html file, not just html files that angular for example may care about. @RyanCavanaugh / @mhegazy Any thoughts on how we should handle this? Right now we just send an open request that looks like:

[Trace  - 5:51:39 PM] Sending request: open (3). Response expected: no. Current queue length: 4
Arguments: {
    "file": "/Users/matb/projects/test-vscode-tsserver-plugin/x.html",
    "fileContent": "#test",
    "projectRootPath": "/Users/matb/projects/test-vscode-tsserver-plugin"
}

Could we add a new scriptKind or argument to open to identify external files?

[RyanCavanaugh]

@mjbvz let's discuss tomorrow