You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support to distinguish diagnostics from TS from the diagnostics from a language server plugin #15224
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.
Cyrille Tuzi (@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?
Mohamed Hegazy (@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.
Cyrille Tuzi (@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.
Activity
cyrilletuzi commentedon Apr 17, 2017
It's already possible, Angular Language Service is already doing it.
mhegazy commentedon Apr 18, 2017
looks like this is covered by #15237
egamma commentedon Apr 18, 2017
Cyrille Tuzi (@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 commentedon Apr 18, 2017
Mohamed Hegazy (@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.jsonfor tslint this is done intslint.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 commentedon Apr 18, 2017
Maybe in the VS Code plugin : https://github.com/angular/vscode-ng-language-service
egamma commentedon Apr 18, 2017
Cyrille Tuzi (@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
sourceattribute in the TS Diagnostic.cyrilletuzi commentedon Apr 18, 2017
Sorry, I forgot about this.
Indeed, when using directly
@angular/language-servicefrom tsconfig.json, errors are just prefixed with[ts].Merge pull request #15296 from Microsoft/Fix15224