(WIP) Use @volar-plugins/eslint instead of ESLint VSCode Extension

[johnsoncodehk]

@volar-plugins/eslint is a Volar LangaugeServicePlugin that support uses ESLint in Volar / Vue Language Server. With this plugin, you can have much better Linting performance in VSCode.

Why @volar-plugins/eslint performance is better?

One of the reasons why ESLint VSCode Extension is slow is that it manages a very expensive TS Program instance that create from TypeScript ESLint plugin, which requires a lot of calculations every time you edit a document.

However, Volar Language Server already has a TS Program, so we can reuse it to avoid repeated calculations.

Other advantages

• It makes ESLint recognize types from .vue in .ts (Using volar together with @typescript-eslint/parser for type checking rules to understand SFC component types #2189)
• Support ESLint for all downstream IDE with coc-volar / nvim-lsp... even if it don't have a ESLint IDE plugin
• It's also supports linting <template>, <style>, <script> from .vue files, which has disabled in sample setup, but you can try remove ignorePatterns: ['**/*.vue.*'] to use as your need.

Usage

1. Install @volar-plugins/eslint to your project
2. Enable Takeover Mode
3. Disable ESLint Extension in your VSCode
4. Reload VSCode

How about CLI?

This plugin only affects IDE, and will not affect CLI.

Problems

It don't support Fix All for now, because I've gotten a lot of complaints in this repo in the past about slow document saving from ESLint's Fix All behavior, we will add it when I have confirm the plugin doesn't cause this problem. (Please open a feature request to https://github.com/johnsoncodehk/volar-plugins/issues if you want to.)

---

Update: Migrate from vue-eslint-parser

Outdated content

@volar-plugins/eslint cannot work well with eslint-plugin-vue, because we cannot pass the TS Program to typescript-eslint/parser of eslint-plugin-vue, but due to @volar /vue-language-server already parses .vue to .vue.ts and feeds to @volar-plugins/eslint, so we don't need eslint-plugin-vue to already be able to support linting for <script> block.

This PR shows how migrate from vue-eslint-parser to @volar-plugins/eslint.

We will going to support vue-eslint-*, please track DrJume/vue-volar-eslint#1

[rchl]

One of the reasons why ESLint VSCode Extension is slow is that it manages a very expensive TS Program instance, which requires a lot of calculations every time you edit a document.

Did you make a typo here or something? I'm fairly sure that the eslint server doesn't use typescript (which I guess is what you are referring to by "TS Program") for anything.

It's also supports linting <template>, <style>, <script> from .vue files,

This is listed as an advantage over eslint extension but eslint extension can also be easily configured to lint *.vue files.

Appreciate the work of course. Just wanted to clarify some points.

[johnsoncodehk]

Did you make a typo here or something? I'm fairly sure that the eslint server doesn't use typescript (which I guess is what you are referring to by "TS Program") for anything.

More precisely TS Program is created by TypeScript ESLint and ESLint just passes it along. So if you haven't had TypeScript ESLint, you probably never noticed the performance issues I mentioned.

This is listed as an advantage over eslint extension but eslint extension can also be easily configured to lint *.vue files.

At this point Volar overlaps with ESLint, @volar-plugins/eslint can already recognize .vue content without configuration. But the virtual files content parsed by Volar (more precisely: @volar/vue-langauge-core) is not generated for linting purposes, so it probably won't pass most of the linting rules, so we just filtered it in the sample setup.

[rchl]

More precisely TS Program is created by TypeScript ESLint and ESLint just passes it along. So if you haven't had TypeScript ESLint, you probably never noticed the performance issues I mentioned.

Yeah, so my point is that saying that "ESLint VSCode Extension is slow is that it manages a very expensive TS Program instance" is not accurate since it's eslint itself or even its plugins do that really.
And I pretty much configure parserOptions.project in all my projects (one public example is https://github.com/rchl/lsp-log-parser/blob/79f59778651aa9a400a44a68820bcd00dd49e39c/.eslintrc.js#L60-L64). I haven't really felt that linting is slow but maybe I haven't worked with big enough projects.

It's also supports linting <template>, <style>, <script> from .vue files,
This is listed as an advantage over eslint extension but eslint extension can also be easily configured to lint *.vue files.

At this point Volar overlaps with ESLint, @volar-plugins/eslint can already recognize .vue content without configuration. But the virtual files content parsed by Volar (more precisely: @volar/vue-langauge-core) is not generated for linting purposes, so it probably won't pass most of the linting rules, so it just filtered it in the sample setup.

So does the original line that I've quoted talks about generated files or just user-written vue blocks?
If user-written then eslint itself can also do that.
If generated then of course only Volar can do that but I'm not sure what would be the purpose of that and how could that be shown to the user.

[johnsoncodehk]

Yeah, so my point is that saying that "ESLint VSCode Extension is slow is that it manages a very expensive TS Program instance" is not accurate since it's eslint itself or even its plugins do that really.

Updated.

I haven't really felt that linting is slow but maybe I haven't worked with big enough projects.

I think your computer is good. :) But if ESLint already fast to you, using @volar-plugins/eslint will be even faster.

So does the original line that I've quoted talks about generated files or just user-written vue blocks?
If user-written then eslint itself can also do that.
If generated then of course only Volar can do that but I'm not sure what would be the purpose of that and how could that be shown to the user.

It's generated. And please check "Update: Migrate from vue-eslint-parser" from the original post.

[yoyo930021]

I think we need to support vue-eslint-parser. If we want to promote the use of everyone.
We have many cross template, script and useful rules in eslint-plugin-vue.

@volar-plugins/eslint cannot work well with eslint-plugin-vue, because we cannot pass the TS Program to typescript-eslint/parser of eslint-plugin-vue

It's not correct for me know.

parserOptions: {
  parser: {
    js: '@typescript-eslint/parser',
    ts: '@typescript-eslint/parser',
    '<template>': 'espree'
  },
  project: './tsconfig.json',
  sourceType: 'module',
  extraFileExtensions: ['.vue']
  programs: [program], // replace eslint typescript program
},

This config is work well in my exp.

Why @volar-plugins/eslint performance is better?

One of the reasons why ESLint VSCode Extension is slow is that it manages a very expensive TS Program instance that create from TypeScript ESLint plugin, which requires a lot of calculations every time you edit a document.

However, Volar Language Server already has a TS Program, so we can reuse it to avoid repeated calculations.

The standalone ESLint VSCode Extension is work better than reuse sometimes.
Maybe we can try to provide standalone package for get vue ts program in this case.

The last, thanks. this is amazing.

It makes ESLint recognize types from .vue in .ts
I have tried to solve this problem, but I don't have time.
ref: vuejs/vue-eslint-parser#104 (comment)

With this package, we have the opportunity to support template type information linting.

cc @ota-meshi by vue-eslint-parser, eslint-plugin-vue maintainer.

[johnsoncodehk]

I think we need to support vue-eslint-parser. If we want to promote the use of everyone.
We have many cross template, script and useful rules in eslint-plugin-vue.
This config is work well in my exp.

I'm open with this, but I got the following error from ESLint when add programs: [program] for vue-eslint-parser.

Parsing error: "parserOptions.programs" has been provided for @typescript-eslint/parser.
The file was not found in any of the provided program instance(s): xxx.vueeslint

I tried it at https://github.com/DrJume/vue-volar-eslint and https://github.com/rchl/lsp-log-parser/tree/test/volar-eslint.

Maybe I did something wrong, if we can have a sample setup repo to show it works it will help.

The standalone ESLint VSCode Extension is work better than reuse sometimes.
Maybe we can try to provide standalone package for get vue ts program in this case.

The purpose here is to reuse the TS Program of Vue Langauge Server to ESLint to improve performance. With the standalone package, the TS Program will be independent. It cannot share state with Vue Langauge Server, so the performance will not be better. (maybe even worse)

With this package, we have the opportunity to support template type information linting.

You can try DrJume/vue-volar-eslint#1, it is supported template type information linting. Because it use the code-gen from Volar, so it got same type information with Volar / vue-tsc.

[DrJume]

I think we need to support vue-eslint-parser. If we want to promote the use of everyone.
We have many cross template, script and useful rules in eslint-plugin-vue.
This config is work well in my exp.

I'm open with this, but I got the following error from ESLint when add programs: [program] for vue-eslint-parser.

Parsing error: "parserOptions.programs" has been provided for @typescript-eslint/parser.
The file was not found in any of the provided program instance(s): xxx.vueeslint

I tried it at https://github.com/DrJume/vue-volar-eslint and https://github.com/rchl/lsp-log-parser/tree/test/volar-eslint.

Maybe I did something wrong, if we can have a sample setup repo to show it works it will help.

The standalone ESLint VSCode Extension is work better than reuse sometimes.
Maybe we can try to provide standalone package for get vue ts program in this case.

The purpose here is to reuse the TS Program of Vue Langauge Server to ESLint to improve performance. With the standalone package, the TS Program will be independent. It cannot share state with Vue Langauge Server, so the performance will not be better. (maybe even worse)

I think I got it to work in https://github.com/DrJume/vue-volar-eslint. But it stills throws the error. I think that's a bug in Volar. (see #2189)

[ota-meshi]

I do not speak English so I do not know if I am writing this well but let me comment. Also because I am busy right now I have not tried @volar-plugins/eslint in detail yet.
First of all, I think both eslint-plugin-vue is superior and @volar-plugins/eslint is superior, so I can't state clearly which one the user should choose.
However, I think @volar-plugins/eslint is by far the superior choice for users writing Vue and TS who want to do linting using types. However, I have heard that it may not be able to be run through the CLI. If it does not work with the CLI, I would appreciate your consideration on that point.

Related to the story @yoyo930021 wrote in the issue, I experimented with passing a special TS Program instance to @typescript-eslint/parser.
vuejs/vue-eslint-parser#104 (comment)
But it did not give better results than the TS Program instance that Volar generates.
It would be really great if TS program instances generated by Volar could be used successfully.

However, eslint-plugin-vue has supported using the ASTs generated by vue-eslint-parser to check the writing style of templates according to user preferences. I am concerned that perhaps it would be difficult to fully support these with the current Volar mechanism.

To begin with, vue-eslint-parser is not designed to accept type checking for template blocks. This is by far the inferior part compared to @volar-plugins/eslint.

This has nothing to do with @volar-plugins/eslint, but I have some ideas to improve the TS problem. But I refrained from trying that with eslint-plugin-vue because of the number of users. So I also worked on the unofficial eslint-plugin-svelte and eslint-plugin-astro and tried some ideas there.

They had some success, but I still think a Volar-generated TS Program instance is a must to do the same thing for *.vue.

I still have no idea for vue-eslint-parser and @volar-plugins/eslint to coexist. But if they can work well together, it would be really great for users who use typescript and eslint with *.vue.

[johnsoncodehk]

First of all thank you for your feedback, having your support will move things forward a lot!

However, I have heard that it may not be able to be run through the CLI. If it does not work with the CLI, I would appreciate your consideration on that point.

For CLI support, here are some ideas:

1. Expose the LSP capabilities to the CLI, like
   • https://github.com/valentjn/lsp-cli
   • https://github.com/vuejs/vetur/tree/master/vti
2. Provide a eslint cli command wrapper vue-eslint (Like tsc -> vue-tsc)
3. Provide a standalone package that creates Volar TS Program to use with typescript-eslint in eslintrc.js

I can't say which is the best way, it still needs more thinking.

On the other hand, it might be too early to support CLI, but if the community does need it in the future, we will provide it in some way.

However, eslint-plugin-vue has supported using the ASTs generated by vue-eslint-parser to check the writing style of templates according to user preferences. I am concerned that perhaps it would be difficult to fully support these with the current Volar mechanism.

I still have no idea for vue-eslint-parser and @volar-plugins/eslint to coexist. But if they can work well together, it would be really great for users who use typescript and eslint with *.vue.

After talking with @yoyo930021 I learned that vue-eslint-parser can selectively remove @typesciprt-eslint/parser, so it should be possible to avoid conflicts with @volar-plugins/eslint, and the end result will be TS Linting is supported by @volar-plugins/eslint + @typescript-eslint/parser, and templates/styles linting is supported by vue-eslint-parser. We just have to figure out an appropriate setting for this. (I think it's promising and I'm excited to it!)

[DrJume]

I think Option 3 provides the most flexibility and support with the ESLint VSCode extension.

On another note, I saw that is it possible to define plugins inside tsconfig.json. Why can't Volar be provided as a TS plugin for CLI use? Then it should work automatically with other tools like ESLint.

[johnsoncodehk]

@DrJume Very good revelation! it's here: #2217

[bradzacher]

I think that implementing a whole new ESLint LSP is going to be a really bad route to go. If you spend just a moment looking at vscode-eslint you'll see why - it is really, really robustly built, provides a lot of features, and handles a lot of edge-cases.

Building another version of it is just asking for maintenance pain and additional pain for your users as they find they're missing features.

For example - quickly browsing the @volar-plugins/eslint codebase - it doesn't look like you don't yet have features like suggestion fixers, disable comment quick-actions, autofix on save.
You could definitely go down the route of building this, or perhaps the better option would be to work on creating a shared ESLint LSP implementation that could be reused between volar and vscode-eslint for the betterment of your users and the entire ecosystem.

That way users don't have to choose between your integrated solution and a feature rich solution - they can just use your solution without any trade-offs. It also would open the door for other IDEs to provide the same feature-rich experience that VSCode has with ESLint - so it's a huge win-win!

[rchl]

OK. Anyways, I'll add my 2 cents then.

If it's the only way to improve performance then I'm all for trying out new things like that.

That said, seeing that Volar is pretty much a one-man project, I don't think it's right to prioritize something like that over fixing core bugs with Volar (and there are quite a few that prevent me from switching over from Vetur).

Personally, the performance of eslint LSP server has not be an issue for me or my colleagues. We run it with fix-on-save enabled in all of our Vue projects.

[johnsoncodehk]

For potential participants, please read these two threads first, where I explain a lot:

• https://discord.com/channels/793943652350427136/899997267149328424
• https://discord.com/channels/688543509199716507/1074327310318186590

I think that implementing a whole new ESLint LSP is going to be a really bad route to go.

I wouldn't call @volar-plugins/eslint "a whole new ESLint LSP" at all. Otherwise you should actually call Volar "a whole new CSS + HTML + TS + Prettier + ... LSP", because these are all under @volar-plugins/*.

If you spend just a moment looking at vscode-eslint you'll see why - it is really, really robustly built, provides a lot of features, and handles a lot of edge-cases.

I understand that VSCode ESLint does a lot of work, but that's not a valid argument for rejecting alternatives for solving real problems. On the other hand, I don't know if it can be called very robust, this repo has been reported a lot of ESLint problems, even people blame Volar for ESLint problems.

Building another version of it is just asking for maintenance pain and additional pain for your users as they find they're missing features.

For example - quickly browsing the @volar-plugins/eslint codebase - it doesn't look like you don't yet have features like suggestion fixers, disable comment quick-actions, autofix on save.

I wouldn't call maintaining a 100-line-of-code plugin a pain. (Dealing with VSCode ESLint complaints is painful instead)

• suggestion fixers, disable comment quick-actions: I could add it in a few minutes, it's just a matter of implementing completeness.
• autofix on save: this is supported

Note that I agree that VSCode ESLint can do other things outside of the ESLint toolkit, it's just that the examples you mentioned lack convincing.

For users, you can say that someone is suffering because of the functionality of @volar-plugins/eslint, but I can also say that someone is suffering because of the performance of VSCode ESLint.

You could definitely go down the route of building this, or perhaps the better option would be to work on creating a shared ESLint LSP implementation that could be reused between volar and vscode-eslint for the betterment of your users and the entire ecosystem.

We're doing this, it's called "Monoserver", but I don't think it can be done without completely refactoring VSCode ESLint. (#2204 (reply in thread))

[johnsoncodehk]

That said, seeing that Volar is pretty much a one-man project, I don't think it's right to prioritize something like that over fixing core bugs with Volar (and there are quite a few that prevent me from switching over from Vetur).

@rchl @volar-plugins/eslint is not specific to Vue/Volar, it applies to all future LSP servers based on Volar.js.

[bradzacher]

I don't know if it can be called very robust, this repo has been reported a lot of ESLint problems, even people blame Volar for ESLint problems.

I mean - it has 25 million installs according to the vscode marketplace, but only has 47 open issues. I'd call that pretty robust, personally - that or they aggressively close bugs to avoid fixing them.

---

but that's not a valid argument for rejecting alternatives for solving real problems

To be clear - I'm not rejecting volar as an alternative, not at all!
Instead I'm suggesting that having an alternative would be great... as long as it's not working to build a brand new LSP implementation for ESLint from the ground-up.

There will be more major releases with more breaking changes to ESLint in future, and I'm sure they'll build new IDE-facing features. Having users held back on ESLint version because they're waiting on their IDE to update is bad. Having different sets of users waiting on different extensions or IDEs to update is worse.

A shared foundation helps alleviate this because everyone gets the same baseline support on top of which to build their customisations (eg volar passing through the ts.Program instance).

[johnsoncodehk]

You could definitely go down the route of building this, or perhaps the better option would be to work on creating a shared ESLint LSP implementation that could be reused between volar and vscode-eslint for the betterment of your users and the entire ecosystem.

After re-reading, I think you are talking about packages like vscode-css-languageservice, vscode-html-languageservice, it would be nice to have eslint-language-service.

Off-topic, I used to make typescript-language-service and pug-language-service for TS and Pug, but because there are no other consumers in reality, they were finally merged into @volar-plugins/typescript, @volar-plugins/pug.

A shared foundation helps alleviate this because everyone gets the same baseline support on top of which to build their customisations (eg volar passing through the ts.Program instance).

I can't imagine an implementation at the moment, it would be great if you could explain more specifically.

[bradzacher]

One of the reasons why ESLint VSCode Extension is slow is that it manages a very expensive TS Program instance that create from TypeScript ESLint plugin, which requires a lot of calculations every time you edit a document.

However, Volar Language Server already has a TS Program, so we can reuse it to avoid repeated calculations.

To be clear - there shouldn't really be any raw performance wins here - volar manages a ts.Program, and @typescript-eslint manages a ts.Program. Both run in separate threads, and both will get updated in response to live changes in the editor. I'd hazard a guess that in most cases there isn't going to be enough load to cause resource contention between threads which slows anything down noticably.

The biggest benefits of using a single ts.Program instance would be:

• reduced memory usage due to no longer needing two copies
• "free" configuration of type-aware linting in the IDE

Though it's worth noting that without the CLI tools you mentioned above - you're probably creating a net worse experience for users because they need to maintain an ESLint config AND a volar config, and they may get two different ESLint results - one in their IDE and one from their CLI.

There's a lot of pros and cons to both approaches, but unless you're going to build a more complete solution so that a user knows that what they see in their IDE will always match what is output from their CLI tools (i.e. what is run against their PRs in their CI) - you're probably just going to be creating a worse and confusing experience for people.

[johnsoncodehk]

Performance is not only about speed, but also about CPU usage, energy consumption. Actually speed is the least important thing for me. For tooling, I think it should always be assumed that the user is using a poor machine (e.g. single core CPU, 2GB Ram).

For the CLI, we will have a "Scripts API" in the future, but it's too early to tell.

[johnsoncodehk]

Closed due to the immaturity of the current solution, even it is currently works, it requires too much user setup (volar.config.js, vue-tsc hook).

We will find a more user-insensitive way to implement it in Volar.js 2.0 with Monoserver and Rules API.

[DrJume]

Looking forward to it 😊

[kieselai]

It looks like this stagnated in February, are there any updates on this?