Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Angular LS as tsserver plugin #338

Closed
kyliau opened this issue Jun 3, 2019 · 16 comments
Closed

Angular LS as tsserver plugin #338

kyliau opened this issue Jun 3, 2019 · 16 comments

Comments

@kyliau
Copy link
Contributor

kyliau commented Jun 3, 2019

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 Allow plugins to provide a list of external files. microsoft/TypeScript#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"
    Add plugins property on TS Server open request microsoft/TypeScript#17151

  2. "Languages provided by plugins not synced"
    typescript: languages provided by plugins not synced microsoft/vscode#75088

@jpike88
Copy link

jpike88 commented Jun 4, 2019

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
Copy link

@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
Copy link
Contributor

  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
Copy link
Contributor Author

kyliau commented Jun 5, 2019

@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
Copy link
Contributor

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
Copy link
Contributor Author

kyliau commented Jun 5, 2019

@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 eclipse-wildwebdeveloper/wildwebdeveloper#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
Copy link
Contributor

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

@Sherloks
Copy link

Do we have an ETA on this?

@jpike88
Copy link

jpike88 commented Jun 25, 2019

@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
Copy link

jpike88 commented Jun 28, 2019

@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
Copy link
Contributor

@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
Copy link

jpike88 commented Jun 28, 2019

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
Copy link
Contributor

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
Copy link

jpike88 commented Jun 28, 2019

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
Copy link
Contributor Author

kyliau commented Aug 29, 2019

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, #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!

@kyliau kyliau closed this as completed Aug 29, 2019
@angular-automatic-lock-bot
Copy link

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.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Feb 16, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants