Vscode-ng-language-service: Angular LS as tsserver plugin

[kyliau]

Here's my attempt at trying to document what I've learned about tsserver plugin so far:

The main benefit of a tsserver plugin is performance. tsserver and the plugin both share the same Typescript instance, so there's no duplicate parsing/compilation. It also addresses the issue with version mismatch.

However, Angular LS has a slightly different requirement, since the plugin would have to handle external (non TS) files as well. These are typically .html files defined via templateUrl in the Angular component.

There are two ways to enable a plugin:

1. via tsconfig.json, aka a "local" plugin

{
  "compilerOptions": {
    "plugins": [
      { "name": "@angular/language-service" }
    ]
  }
}

Issue: this only works for Typescript files.

1. via a vscode extension, aka a "global" plugin
   "contributes": { "typescriptServerPlugins": [ { "name": "@angular/language-service" } ] },
   Here we could associate the plugin with a list of languages, see below.

Once the plugin is loaded, there are two ways to define external files:

1. The plugin itself returns a list of external files through getExternalFiles().
   This is implemented in https://github.com/microsoft/TypeScript/pull/15308, but seems to be less preferable compared to the second approach below.

2. Associate plugin with a set of languages.

"contributes": { "typescriptServerPlugins": [ { "name": "@angular/language-service", "enableForWorkspaceTypeScriptVersions": true, "languages": [ "html" ] } ] },
Whenever a file that matches the language is opened, the plugin will be notified.

Issues

1. As of vscode 1.34.0 and typescript 3.4.5, registering the plugin with languages seems to have no effect. The plugin simply isn't notified about the external files.

2. Assume (1) above is resolved, the plugin needs to make sure HTML are not parsed as TS files.

3. HTML files should not be parsed as TS when the plugin is not present.

4. What if .html is open but none of the TS file are?

5. Syntax highlighting missing after fixing (2).

Related

1. "Add plugins property on TS Server open request"
   https://github.com/Microsoft/TypeScript/issues/17151

2. "Languages provided by plugins not synced"
   https://github.com/microsoft/vscode/issues/75088

[jpike88]

That other plugin that did it... can you learn some lessons from it to speed up dev?

https://github.com/cyrilletuzi/vscode-typescript-angular-plugin

[SteffenKoehler]

@jpike88 the other plugin only did it for inline templates and not for external .html files and this (that's how I understood it) is the main problem.
As kyliau mentioned in this issue microsoft/TypeScript#17151, he made it work for the inline templates - what's missing are the external html files

[andrius-pra]

1. As of vscode 1.34.0 and typescript 3.4.5, registering the plugin with languages seems to have no effect. The plugin simply isn't notified about the external files.

@kyliau I have managed to activate angular typescipt plugin in vscode. I did changes in vscode and angular language service. I also have to add this this setting to settings.json: "typescript-plugins.suggest.enabled": true

[kyliau]

@andrius-pra thanks for the suggestion! I'll try it out. What about non-Angular html files? Did you see any errors on those?

[andrius-pra]

Typescript do types checking only for project root files. So by default it doesn't show any error for html files. I use non public api to add html files to project root here.
I don't see typescript errors in html(angular and non-angular) files because i don't call native getSemanticDiagnostics and getSyntacticDiagnostics methods for html files

[kyliau]

@andrius-pra I agree with the modification to filter out diagnostics for HTML files in Angular, but I don't think the hack to add missing file root is needed, because that's the whole point of declaring "languages" in "typescriptServerPlugins", isn't it?
In https://github.com/eclipse/wildwebdeveloper/issues/138, @mickaelistria reported that TS diagnostics are shown in HTML files without any additional config. This used the behavior that I saw before, but I was no longer able to reproduce it.

[andrius-pra]

@kyliau , we don't need this hack. I'm able to get diagnostic errors with changes in typescript, vscode and angular.

[Sherloks]

Do we have an ETA on this?

[jpike88]

@SteffenKoehler this plugin

https://github.com/cyrilletuzi/vscode-typescript-angular-plugin

That doesn't even work with inline templates.

But I'm using it instead because it is far more performant. This official one is sluggish and sometimes hovering over a definition takes ages for it to show the popover.

[jpike88]

@kyliau God things are moving so sluggishly on this project. Typically I'd throw money at it to help move it along, but this is a Google in-house project. Considering how widespread VSCode is used, and how integral TS is to Angular, why isn't this getting more activity? Shouldn't there be at least 2 employees assigned to this??

[mickaelistria]

@kyliau Have you considered contributing patches instead of complaining? That's how OSS works: people providing code get the influence, if you want more influence, provide more code. Or maybe buy and run Google Inc. to make sure you'll be free to assign as much of its staff you want on the project.

[jpike88]

I contribute to enough OSS projects as it is without needing to be talked down to like that. You're contributing even less than I am by assuming that every person giving things a poke is some kind of freeloader.

[mickaelistria]

There are different way of giving things a poke, yours in previous comment wasn't really formed in a constructive way for the project and seemed blaming more than constructive.

[jpike88]

Don't you have better things to do than trying to police how other people communicate? My question was addressed to the project maintainers, so why don't you mind your own business?

[kyliau]

After much deliberation and discussion with the TypeScript team, we've decided that the Angular language service will not be purely a tsserver plugin.

This means:

1. The plugin model would still be maintained, albeit without external template support.
   Users who don't use external templates and don't want to install the extension could just install the plugin per-project via tsconfig.json.
2. The current extension has a new implementation that loads the plugin internally. This new prototype is much more efficient (faster), but still hosts its own TypeScript compiler.

This does not mean:

1. The plugin will never support external template.
   If work is done by the community to make tsserver support files other than JS/TS, then Angular plugin could transition to that model easily.

The main reasons for this are:

1. Compatibility with Language Server Protocol (LSP)
   Maintaining compatibility with LSP is essential to support editors other than vscode.
2. Flexibility of vscode extension
   The extension is much more capable than the tsserver plugin, hence maintaining our own extension allows us to add more editor features in the future.

Going forward, https://github.com/angular/vscode-ng-language-service/issues/335 will be used to track the progress of remaining work items for the language service. If you run into specific plugin problems, please open a new issue, thank you!

[angular-automatic-lock-bot[bot]]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{_This action has been performed automatically by a bot._}