Support to distinguish diagnostics from TS from the diagnostics from a language server plugin

[egamma]

Experimenting with tslint running as a language server plugin.

When providing the diagnostics from tslint from the language server plugin decorator, then the diagnostics cannot be distinguished from the original typescript diagnostics, see below:

With the existing vscode-tslint extension we prefix the message with the source of the diagnostic, e.g., tslint.

[cyrilletuzi]

It's already possible, Angular Language Service is already doing it.

[mhegazy]

looks like this is covered by #15237

[egamma]

@cyrilletuzi goodness, do you have a pointer? I've looked here. However, I only see that the code sets the DiagnosticCategory, an error from the angular language service will still show up as an error from TypeScript (prefix '[ts]' in VS Code) or am I missing something?

[egamma]

@mhegazy issue #15237 is about distingushing between warnings and errors. This issue related but different. It is about distinguishing warning/errors that come from TS and warnings that come from TSLint. To make this more clear here is an example from how the diagnostics show up in VS Code.

This is an error from TypeScript, notice the [ts] prefix:

This is a warning from tslint, notice the [tslint] prefix:

This source of a diagnostic is important when the user wants to configure a diagnostics, e.g., for TS diagnostics this is done in the tsconfig.json for tslint this is done in tslint.json.

In the VS Code diagnostics API a diagnsotic has an optional field source, that the creator of a diagnostic can set and this then rendered in the UI.

(removing the duplicate label)

[cyrilletuzi]

Maybe in the VS Code plugin : https://github.com/angular/vscode-ng-language-service

[egamma]

@cyrilletuzi thanks the pointer, but please keep in mind that the VS Code angular language service extension is not yet using the TS language server plugin support and runs a duplicate TypeScript language server. In this setup the extension can use the VS Code diagnostic API to set the source of the diagnostic to Angular, which it does here.

Once the angular language service extension runs as a TS language server plugin this will no longer be possible. So this is another scenario that there is a need for an optional source attribute in the TS Diagnostic.

[cyrilletuzi]

Sorry, I forgot about this.

Indeed, when using directly @angular/language-service from tsconfig.json, errors are just prefixed with [ts].