ESLint extension making VSCode IntelliSense and linting very slow

[tiago-eusebio-dev]

On the latest VSCode 1.74.0 and 1.74.1 the ESLint extension makes the IntelliSense and linting to be very slow.
After uninstalling the extension everything becomes fast again.
Disabling the extension maintains the issue.

On VSCode 1.73.1 the issue does not occur.

VSCode Version: 1.74.1
ESLint extension version: v2.2.6 and v.2.3.0 (pre-release)

eslintrc.json file:

{
	"root": true,
	"ignorePatterns": ["projects/**/*", "**/*.stories.ts"],
	"overrides": [
		{
			"files": ["*.ts"],
			"parserOptions": {
				"project": ["tsconfig.json", "e2e/tsconfig.json"],
				"createDefaultProgram": true
			},
			"extends": [
				"plugin:@angular-eslint/ng-cli-compat",
				"plugin:@angular-eslint/ng-cli-compat--formatting-add-on",
				"plugin:@angular-eslint/template/process-inline-templates"
			],
			"rules": {
				"@angular-eslint/component-selector": [
					"error",
					{
						"type": "element",
						"style": "kebab-case"
					}
				],
				"@angular-eslint/directive-selector": [
					"error",
					{
						"type": "attribute",
						"style": "camelCase"
					}
				],
				"@typescript-eslint/member-ordering": [
					"error",
					{
						"default": {
							"memberTypes": [
								"decorated-field",
								"public-field",
								"field",
								"constructor",
								"public-method",
								"method",
								"private-method"
							],
							"order": "as-written"
						}
					}
				],
				"no-underscore-dangle": ["off"]
			}
		},
		{
			"files": ["*.html"],
			"extends": ["plugin:@angular-eslint/template/recommended"],
			"rules": {}
		}
	]
}

.eslintignore file:

node_modules/
dist/

[MariaSolOs]

@tiago-eusebio-pbss Do you have any specific extension settings? If so, take a look at #1538 (comment) for possible optimizations.

It's really hard to isolate what exactly is causing the performance problem, but from looking at your config, I wouldn't think that it's entirely due to this extension. Angular + typed linting can get quite heavy (the plugin even acknowledges this in their repo).

I can understand your frustration though: These tools should ease and improve our development process, not clutter it. Maybe once #1542 is implemented you'll obtain a better perf diagnosis.

[tiago-eusebio-dev]

@MariaSolOs Thank you for answering.

The VSCode preferences related to the editor are the following:

 (...)
 "editor.formatOnSave": true,
  "editor.formatOnType": true,
  "editor.formatOnPaste": true,
  "editor.trimAutoWhitespace": true,
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": true
  },
  "[typescript]": {
    "editor.codeActionsOnSave": {
      "source.organizeImports": true
    }
  },
  "typescript.preferences.importModuleSpecifier": "relative",
(...)

Maybe we can add the following preference, but not having it was not an issue previously:

"eslint.codeActionsOnSave.mode": "problems"

I can confirm that the performance problem is related to the extension, as we no longer have this issue if we uninstall it.
I can assume that the problem is not related with the settings, because we are using those same settings for months with no issues.

Furthermore, going back to VSCode v1.73.1 with the exact same extension and settings, the issue does not occur.

That being said, I assume that something on the new VSCode version (v1.74.x) introduced a conflict with the extension.

Thank you

[dbaeumer]

@tiago-eusebio-pbss could you share a GitHub repository that we can clone that demos what you are seeing. Performance problems like this depend on so many varaibles (version, plugins, ....). In addition two things are strange:

Disabling the extension maintains the issue.

Disabling an extension results in not loading it's code at all in VS Code.

IntelliSense and linting to be very slow.

The ESLint extension doesn't provide any IntelliSense information and hence has no influence on the performance of that operation in VS Code.

Both points indicate that the actual problem might lay somewhere else. So steps to reproduce would help a lot to understand what is going on.

[tiago-eusebio-dev]

After some more hours debugging you were right. The problem is not related with the ESLint extension but one of our proprietary dependencies.
If we remove it, the issue doesn't occur.

Strangely it only occurs with the new VSCode version, but thats a story for another place :)
Thank you

[litera]

After some more hours debugging you were right. The problem is not related with the ESLint extension but one of our proprietary dependencies. If we remove it, the issue doesn't occur.

Which dependecy would that be, because I'm hitting a major performance hit since VSCode got upgraded few versions ago. I didn't give it much attention then. because I thought it will be resolved with some newer version, but it became really annoying that my Intellisense is a hit & miss. Sometimes it works, sometimes it just doesn't...

[tiago-eusebio-dev]

After some more hours debugging you were right. The problem is not related with the ESLint extension but one of our proprietary dependencies. If we remove it, the issue doesn't occur.

Which dependecy would that be, because I'm hitting a major performance hit since VSCode got upgraded few versions ago. I didn't give it much attention then. because I thought it will be resolved with some newer version, but it became really annoying that my Intellisense is a hit & miss. Sometimes it works, sometimes it just doesn't...

It is an internal dependency created by our team.
Another issue was that the TypeScript version included with VSCode is higher than the one supported by our projects (currently 4.8.4) which would cause errors and performance issues.

The way we solved it was to put a config on VSCode (.vscode/settings.json) pointing to the workspace's own TS lib:
"typescript.tsdk": "<workspace>\\node_modules\\typescript\\lib"

[matthew-dean]

The way we solved it was to put a config on VSCode (.vscode/settings.json) pointing to the workspace's own TS lib:
"typescript.tsdk": "\node_modules\typescript\lib"

Ahhhh I wish I had found this months ago. I don't know why this works or why the ESLint VSCode extension takes minutes (minutes!) to fix a single file without it, but seemingly had nothing to do with my rules or other extensions. It was just setting typescript.tsdk that fixes it (even though every package in our monorepo uses the same version of TypeScript 🤷‍♂️ )

[denny-sam-sahaj]

This is the real solution. My linting is instantaneous now. I use a mac and I don't use a workspace. The setting that I use is
"typescript.tsdk": "./node_modules/typescript/lib" given that there's node_modules in your root directory.

[nelisbijl]

Another completely different use case that causes the Eslint plugin to slow down dramatically (up to 30s on M2 Max): the combined Vue construct: readonly(reactive(...)))

import { beforeEach, describe, expect, it, vi } from 'vitest';
import type { DeepReadonly, Reactive, UnwrapNestedRefs } from 'vue';

// the readonly(reactive(...)) causes the VS Code Eslint plugin to slow down dramatically
const wrap = <T extends Record<string, unknown>>(obj: T): DeepReadonly<UnwrapNestedRefs<Reactive<T>>> => {
  return readonly(reactive(obj));
};

// turns out using only readonly(...) has the same desired effect and does not slow down the Eslint plugin
// comment out the previous version of wrap and uncomment this one
// const wrap = <T extends Record<string, unknown>>(obj: T): DeepReadonly<UnwrapNestedRefs<T>> => {
//   return readonly(obj);
// };

describe('slow eslint plugin', () => {
  const someConst = 'hello world';
  const someRef = ref(0);
  const someFn = vi.fn();

  const wrapped = wrap({ someConst, someRef, someFn });

  beforeEach(() => {
    someRef.value = 0;
    someFn.mockRestore();
  });

  it('should pass someConst', () => {
    expect(wrapped.someConst).toBe('hello world');
  });

  it('should pass someRef', () => {
    expect(wrapped.someRef).toBe(0);
  });

  it('should pass someFn', () => {
    wrapped.someFn();
    expect(someFn).toHaveBeenCalledOnce();
  });

  it('should pass someRef change', () => {
    expect(wrapped.someRef).toBe(0);
    someRef.value = 1;
    expect(wrapped.someRef).toBe(1);
  });

  it('wrapped should be readonly', () => {
    // eslint-disable-next-line @typescript-eslint/no-unsafe-type-assertion, @typescript-eslint/no-explicit-any
    const wrp = wrapped as any;
    wrp.someConst = 'bye moon';
    wrp.someRef = 8;
    const newFn = vi.fn();
    wrp.someFn = newFn;
    expect(wrapped.someConst).toBe('hello world');
    expect(wrapped.someRef).toBe(0);
    wrapped.someFn();
    expect(someFn).toHaveBeenCalledOnce();
    expect(newFn).not.toHaveBeenCalled();
  });
});

[dbaeumer]

@nelisbijl can you share a repository the demos that. How does validation perform in the terminal on that file?

[nelisbijl]

Everything you need is in this single file

✓ src/test-helpers/slowEslintPlugin.spec.ts (5)
   ✓ slow eslint plugin (5)
     ✓ should pass someConst
     ✓ should pass someRef
     ✓ should pass someFn
     ✓ should pass someRef change
     ✓ wrapped should be readonly

 Test Files  1 passed (1)
      Tests  5 passed (5)
   Start at  10:57:19
   Duration  123ms```

[dbaeumer]

Things like this mostly depend on the version of ESLint, its plugin, .... So a setup I can clone is highly appreciated.

[nelisbijl]

Turns out Eslint CLI is slow as well:
https://github.com/nelisbijl/slow-eslint

[dbaeumer]

Thanks for the repository.

If the CLI is slow as well the only thing you can do is to tweak the rules that get executed during linting or code action on save. For code action on save you can even override the rules using VS Code settings (eslint.codeActionsOnSave.rules)

eslint.debug is very helpful here as well. You can enable it and then get a detailed trace inside the ESLint output channel. Helps to find rules that are slow during linting.