vue-eslint-parser and typescript-eslint problems

[yoyo930021]

Reason: typescript-eslint/typescript-eslint#2865 (comment)

Hi, I'm using vue-eslint-parser and typescript-eslint in company project.
At the same time, I also help to contribute typescript-eslint project for fixing vue problems.

This problems are only happens when using type rules in typescript-eslint.
You need to add parserOptions.project in project to enable it.
https://github.com/typescript-eslint/typescript-eslint/blob/master/docs/getting-started/linting/TYPED_LINTING.md

There are two main issues:

performance issue

issues: #65, typescript-eslint/typescript-eslint#1180

The problem is that vue-eslint-parser is designed with the AST not type information.
The vue-eslint-parser will split code frame from template to @typescript-eslint/parser.
typescript-eslint/typescript-eslint#1180 (comment)
Typescript program need to parse full project for generate type information.
When parsing code frame, typescript program will reparse file AST and rebuild type information in project.
The vue-eslint-parser will pass more code frames and same file path in single Vue SFC.

Possible solutions:

1. Ignore parserOptions.project to close get type information when pass code frame.
2. Try to use ESLint processors, like Svelte.
   Ref: Add fragment options to lint code fragment for Vue SFC performance typescript-eslint/typescript-eslint#1180 (comment)

[no-unsafe-*] rules

issues: typescript-eslint/typescript-eslint#2865

Strictly speaking, it isn't a problem with this project.
The typescript program can't parse Vue SFC file directly.

You may think it's strange, but why is it working now?
Because @typescript-eslint/parser will prioritize the content delivered from ESLint.
Typescript program will update by ESLint content not same as typescript program read.
But this problem is happens when ESLint not send file content and content from typescript program reading.
Example:

// App.vue
import HelloWorld from './components/HelloWorld.vue' // <- typescript program can't parse it. because it will read including template and style.

export default {
  name: 'App',
  components: {
    HelloWorld // <- so type information is `any`
  }
}

This problem will also have in <script setup> RFC.

Possible solutions:

1. Override HelloWorld.vue content.
2. Mock a HelloWorld.vue.ts file.

Maybe we need a common project for hacking typescript program.

Thanks for watching. Have a good day!

[ota-meshi]

Thank you for organizing information.
(I take a long time to read English, so first I'm trying to understand performance issues. 😅)
I understand, thanks to your explanation, that the main cause is to call as many TS parsers as there are directives.

Ignore parserOptions.project to close get type information when pass code frame.

If this method solves the problem, I think it's the simplest change.
Is it possible for you to make this change and see if it improves performance?

Try to use ESLint processors, like Svelte.
Ref: typescript-eslint/typescript-eslint#1180 (comment)

I don't think we can use the ESLint processors.
It's difficult to change in vue-eslint-parser to do something similar to preprocessors, but I think it's more likely than ESLint processors.
As far as I can think of now, it's difficult to analyze variables in template scope.

[yoyo930021]

(I take a long time to read English, so first I'm trying to understand performance issues. 😅)

My English is poor. If you don't understand what do I talk about, maybe I can ask for help. 😅

Ignore parserOptions.project to close get type information when pass code frame.

If this method solves the problem, I think it's the simplest change.
Is it possible for you to make this change and see if it improves performance?

I will try again about this solution, and send a PR.
Maybe we can split two parser options for code frame and script. Ref: #65 (comment)

Try to use ESLint processors, like Svelte.
Ref: typescript-eslint/typescript-eslint#1180 (comment)

I don't think we can use the ESLint processors.
It's difficult to change in vue-eslint-parser to do something similar to preprocessors, but I think it's more likely than ESLint processors.
As far as I can think of now, it's difficult to analyze variables in template scope.

In the long run, we hope that the template can get the type information and rules.
There is actually no difference between parser and processors.
The parser also can compile templates to typescript and get type information with @typescript-eslint.
Perhaps the question is whether there is a need?

[mariusheine]

Are there any information, progress or ideas for the problem with the [no-unsafe-*] rules?

[JounQin]

@ota-meshi Even after #116, there is no way to only enable typescript rules for <script lang="ts">, right? Because we can only enable rules for *.vue files, not *.vue/*.ts.

[ota-meshi]

I know it.
I wrote #116 as "Related" because it may solve the performance issue depending on how it is used.

[ota-meshi]

I changed parserOptions.parser to allow multiple parsers.
If someone has an environment where they can try out performance issues, can you use the following configuration to see if it improves performance and share the results?

{
    "parser": "vue-eslint-parser",
    "parserOptions": {
        "parser": {
            "ts": "@typescript-eslint/parser",
            "<template>": "espree"
        }
    }
}

If performance improves, I think it's a useful workaround for many.

[tjk]

@ota-meshi I tried your patch and it made a huge difference!

Before (~10 seconds):

$ npx eslint --debug --fix frontend-next/src/components/connection/filters/app-filter.vue
...
  eslint:cli-engine Lint .../frontend-next/src/components/connection/filters/app-filter.vue +0ms
  eslint:linter Linting code for .../frontend-next/src/components/connection/filters/app-filter.vue (pass 1) +0ms
  eslint:linter Verify +0ms
  eslint:linter With ConfigArray: .../frontend-next/src/components/connection/filters/app-filter.vue +0ms
  eslint:linter Apply the processor: 'vue/.vue' +0ms
  eslint:linter A code block was found: '(unnamed)' +1ms
  eslint:linter Generating fixed text for .../frontend-next/src/components/connection/filters/app-filter.vue (pass 1) +9s
...
.../frontend-next/src/components/connection/filters/app-filter.vue
  108:22  warning  The "update:value" event has been triggered but not declared on `emits` option  vue/require-explicit-emits

After (~instant):

$ npx eslint --debug --fix frontend-next/src/components/connection/filters/app-filter.vue
...
  eslint:cli-engine Lint .../frontend-next/src/components/connection/filters/app-filter.vue +0ms
  eslint:linter Linting code for .../frontend-next/src/components/connection/filters/app-filter.vue (pass 1) +0ms
  eslint:linter Verify +0ms
  eslint:linter With ConfigArray: .../frontend-next/src/components/connection/filters/app-filter.vue +1ms
  eslint:linter Apply the processor: 'vue/.vue' +0ms
  eslint:linter A code block was found: '(unnamed)' +0ms
  eslint:traverser Unknown node type "ChainExpression": Estimated visitor keys ["type","start","end","loc","range","expression"] +0ms
  eslint:linter Generating fixed text for .../frontend-next/src/components/connection/filters/app-filter.vue (pass 1) +135ms
...
.../frontend-next/src/components/connection/filters/app-filter.vue
  108:22  warning  The "update:value" event has been triggered but not declared on `emits` option  vue/require-explicit-emits

Produced same lint warning both times so reassuring. Is Unknown node type "ChainExpression": Estimated visitor keys ["type","start","end","loc","range","expression"] something to look into?

[lovetingyuan]

I changed parserOptions.parser to allow multiple parsers.
If someone has an environment where they can try out performance issues, can you use the following configuration to see if it improves performance and share the results?

{
    "parser": "vue-eslint-parser",
    "parserOptions": {
        "parser": {
            "ts": "@typescript-eslint/parser",
            "<template>": "espree"
        }
    }
}

If performance improves, I think it's a useful workaround for many.

how to set different parser options for each parserOptions.parser ? @ota-meshi

[ota-meshi]

There is no way to do that.

[simllll]

If I run it via CLI
e.g. eslint src/file.ts --ext ts
it throws 7:13 error Parsing error: Unexpected token {
for

it seems it always picks "espree" instead of the rule that should forward it to the typesint-eslint/parser in case it's a ts file?

a possible workaround for now:

overrides: [
		{
			// enable the rule specifically for TypeScript files
			files: ['*.ts', '*.tsx'],
			parserOptions: {
				parser: '@typescript-eslint/parser'
			}
		}
	],

[yoyo930021]

If I run it via CLI
e.g. eslint src/file.ts --ext ts
it throws 7:13 error Parsing error: Unexpected token {
for

it seems it always picks "espree" instead of the rule that should forward it to the typesint-eslint/parser in case it's a ts file?

a possible workaround for now:

overrides: [
		{
			// enable the rule specifically for TypeScript files
			files: ['*.ts', '*.tsx'],
			parserOptions: {
				parser: '@typescript-eslint/parser'
			}
		}
	],

Try this config.

{
    "parser": "vue-eslint-parser",
    "parserOptions": {
        "parser": {
            "ts": "@typescript-eslint/parser",
            "js": "@typescript-eslint/parser",
            "<template>": "espree"
        }
    }
}

[yoyo930021]

@ota-meshi Thank you for the help.
I'm sorry for being late to reply.

Test result:

Project 1

• Previous
  • 56.40s
  • 60.02s
• Now
  • 31.76s
  • 34.21s

Project 2

• Previous
  • 355.39s
  • 333.68s
• Now
  • 51.07s
  • 56.20s

The effect is remarkable.

[yoyo930021]

Are there any information, progress or ideas for the problem with the [no-unsafe-*] rules?

No method other than hacking @typescript-eslint/parser. =_=