Bug: no-unsafe-argument takes several seconds to analyze very small repo

[aKzenT]

Before You File a Bug Report Please Confirm You Have Done The Following...

• I have tried restarting my IDE and the issue persists.
• I have updated to the latest version of the packages.
• I have searched for related issues and found none that matched my issue.
• I have read the FAQ and my problem is not listed.

Issue Description

Running eslint on the sample repo provided that just consists of two very simple files takes several seconds. Almost all of that time is spent in the no-unsafe-argument rule. The issue seems to be connected to some of the libraries installed. E.g. removing vuelidate fixes the problem.

Rule                                      | Time (ms) | Relative
:-----------------------------------------|----------:|--------:
@typescript-eslint/no-unsafe-argument     |  4828.500 |    99.2%
@typescript-eslint/no-misused-promises    |    24.462 |     0.5%
@typescript-eslint/no-unused-vars         |     2.219 |     0.0%
@typescript-eslint/no-unsafe-assignment   |     1.496 |     0.0%
no-redeclare                              |     1.270 |     0.0%
@typescript-eslint/ban-types              |     0.607 |     0.0%
@typescript-eslint/no-empty-function      |     0.570 |     0.0%
no-global-assign                          |     0.520 |     0.0%
@typescript-eslint/triple-slash-reference |     0.452 |     0.0%
no-misleading-character-class             |     0.366 |     0.0%

Updating to latest vue version causes another error:

RangeError: Maximum call stack size exceeded
Occurred while linting C:\enbw\testeslint\A.vue:9
Rule: "@typescript-eslint/no-unsafe-argument"
    at getMappedType (C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:63282:31)
    at getMappedType (C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:63299:30)
    at C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:63432:82
    at Object.map (C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:638:29)
    at getObjectTypeInstantiation (C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:63432:40)
    at instantiateTypeWorker (C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:63666:28)
    at instantiateTypeWithAlias (C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:63646:26)
    at instantiateType (C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:63629:37)
    at instantiateList (C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:63257:34)
    at instantiateTypes (C:\enbw\testeslint\node_modules\typescript\lib\typescript.js:63271:20)

Reproduction Repository Link

https://github.com/aKzenT/eslint-problem

Repro Steps

1. clone the repo
2. npm install
3. TIMING=1 npm run eslint

Versions

package	version
@typescript-eslint/eslint-plugin	5.33.1
@typescript-eslint/parser	5.33.1
TypeScript	4.7.4
ESLint	8.22.0
node	18.4.0

[bradzacher]

Have you checked out our FAQ on slow linting?
https://typescript-eslint.io/docs/linting/troubleshooting/#my-linting-feels-really-slow

---

ESLint perf timing is a bit misleading because it times things naively.

TS types are computed lazily - which means the first rule that runs and accesses type information will be the one that gets "hit" with the cost of calculating them. Subsequent rules can then access the same types for free because they hit the cache.

This can be illustrated by turning the no-unsafe-argument rule off - you'll notice that a different type-aware rule will have its attributed runtime increase in its stead as it takes on the type calculation.

[aKzenT]

Thanks for the quick response. I have read the FAQ, but I don't think the caveats mentioned there apply here:

• My tsconfig doesn't specify any include, but the repo does not contain any build outputs or other stuff that could be included by accident. node_modules should be excluded by default. Just to make sure I added an include option of "*.vue" to tsconfig.json locally and it did not change the timing.
• There is only a single tsconfig.json specified in the eslint-config
• The repro only consists of two files to be linted which are mostly empty
• In the original project where I created the repro from compilation times are a lot faster than linting and the linting process takes several minutes

You are correct on the misleading timing though. Disabling the no-unsafe-arguments does not solve the problem it just shifts the linting time to the next rule.

[bradzacher]

The FAQ links to this doc which also outlines the performance implication of using type-aware linting https://typescript-eslint.io/docs/linting/typed-linting#how-is-performance

In a nutshell - slower linting is expected and unavoidable.