Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
4 tasks done
aKzenT opened this issue Aug 17, 2022 · 3 comments
Closed
4 tasks done

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

aKzenT opened this issue Aug 17, 2022 · 3 comments
Labels
working as intended Issues that are closed as they are working as intended

Comments

@aKzenT
Copy link

aKzenT commented Aug 17, 2022

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
@aKzenT aKzenT added bug Something isn't working triage Waiting for team members to take a look labels Aug 17, 2022
@bradzacher
Copy link
Member

bradzacher commented Aug 17, 2022 •
edited
Loading

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.

@bradzacher bradzacher added awaiting response Issues waiting for a reply from the OP or another party and removed bug Something isn't working triage Waiting for team members to take a look labels Aug 17, 2022
@aKzenT
Copy link
Author

aKzenT commented Aug 17, 2022

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
Copy link
Member

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.

@bradzacher bradzacher added working as intended Issues that are closed as they are working as intended and removed awaiting response Issues waiting for a reply from the OP or another party labels Aug 17, 2022
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
working as intended Issues that are closed as they are working as intended
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@aKzenT @bradzacher