Just so I'm understanding correctly - the language server plugin exists to:

• let you reuse the program already setup by the language server so it's faster.
• let you provide your warnings/errors via the typescript LS instead of via an IDE plugin

Does it give you any other benefits at compile time? i.e. if I run tsc, will it report the errors from my plugin on the command line?

Does it give you any other benefits at compile time?

No microsoft/TypeScript#16607

* let you provide your warnings/errors via the typescript LS instead of via an IDE plugin

Plus, integrates with the codefix suggestions, so autofix all problems or autofix on save works more seamlessly.

@mohsen1 I was under the impression that this ticket was only about allowing plugins to modify the transpilation output, not the command line output?

@MayhemYDG My understanding is that plugins are only for tsserver. They can provide errors, warnings and QuickFixes but when using the compiler command line tool (tsc) plugin is ignored

Ah I see, that makes sense. Unfortunate that tsc doesn't use the plugins.

Just for reference, I found some docs about that here: https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin

Hi guys. I'm loving tsserver and TypeScript's language service.

So I've created a language service plugin for ESLint, https://github.com/Quramy/typescript-eslint-language-service . To use this plugin, npm i typescript-eslint-language-service and configure your tsconfig.json such as:

{
  "compilerOptions": {
    "module": "commonjs",
    "target": "es5",
    "plugins": [
      {
        "name": "typescript-eslint-language-service"
      }
    ]
  }
}

This plugin depends on only the following packages:

• typescript
• eslint
• @typescript-eslint/parser

And this plugin gets ts.sourceFile instance from LanguageService's program and creates ESLint SourceCode instance with parsing to estree AST from the ts.sourceFile instance. In other words, this plugin re-uses the language service's tokenized result.

I'm welcome for PRs or feedbacks ;)

Thanks a lot for putting that together @Quramy! I can see a few areas for improvement:

1. Don't deep import private symbols from the packages you depend on, this makes your code more likely to break as those things are subject to change at any time given they are not part of the public API

2. Reduce areas of duplication: right now it looks like you are having duplicate (or create code very similar to) quite a few different parts of our codebase

For (1) and (2) if there are APIs/points of extension we don't currently provide from our packages, just let us know and we can look at providing them where it makes sense!

3. Be explicit about the fact that you do actually depend on typescript-estree as well, not just parser

Thanks again for all your work on this, it's great to have different choices available for IDE setups!

@JamesHenry Thanks for your feedback.

You’re right. For now, I use some internal APIs and duplicate some codes to directly convert from ts AST(not text) to ESLint AST. I want some public APIs so I’ll report them later.

About (3), using typescript-estree is temporary. If the above duplication is removed, I can remove the dependency.

@Quramy amazing! Thank you.

Usage with Sublime Text LSP is flawless.

I'm going to close this as it's not something we're going to look to support ourselves now or in the near future.

Quramy has done a great job and has an existing solution that people can use if they wish.