8000 Bug: Reproducible `allowAutomaticSingleRunInference` failure · Issue #5880 · typescript-eslint/typescript-eslint · GitHub
[go: up one dir, main page]
Skip to content

Bug: Reproducible allowAutomaticSingleRunInference failure #5880

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
aaronadamsCA opened this issue Oct 25, 2022 · 9 comments · Fixed by #5893
Closed
4 tasks done

Bug: Reproducible allowAutomaticSingleRunInference failure #5880

aaronadamsCA opened this issue Oct 25, 2022 · 9 comments · Fixed by #5893
Labels
accepting prs Go ahead, send a pull request that resolves this issue bug Something isn't working

Comments

@aaronadamsCA
Copy link

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

I believe I've reproduced #5136.

I seem to have it narrowed down to the following very specific combination:

  • Using typescript-eslint together with eslint-plugin-import;
  • Using allowAutomaticSingleRunInference;
  • Importing from "@mui/joy/styles" - it seems this import is haunted somehow.

Even weirder - it doesn't always reproduce locally, but fails every time when running on GitHub Actions:

https://github.com/aaronadamsCA/typescript-eslint-issue-5136/actions/runs/3321426085/jobs/5489056308

This was not easy to isolate, but hopefully this reproduction can help resolve the issue for good.

For now we will simply disable allowAutomaticSingleRunInference in our repositories to avoid this issue.

Reproduction Repository Link

https://github.com/aaronadamsCA/typescript-eslint-issue-5136

Repro Steps

  1. clone the repo
  2. yarn install
  3. yarn run check

Versions

package version
@typescript-eslint/eslint-plugin 5.41.0
@typescript-eslint/parser 5.41.0
TypeScript 4.8.4
ESLint 8.26.0
node 16.17.0

Also note Gatsby has a transitive dependency on @typescript-eslint/eslint-plugin@npm:4.33.0, but I don't believe this is related.
@aaronadamsCA aaronadamsCA added bug Something isn't working triage Waiting for team members to take a look labels Oct 25, 2022
@JoshuaKGoldberg
Copy link
Member

Now this is interesting! From the log:

Warning:   0:1   warning  This rule requires the `strictNullChecks` compiler option to be turned on to function correctly  @typescript-eslint/no-unnecessary-condition

But, the tsconfig does include include "extends": "@tsconfig/strictest/tsconfig.json": https://github.com/aaronadamsCA/typescript-eslint-issue-5136/blob/d217e057ee8c9b6c809a1115612e58af079b73c3/tsconfig.json#L2

Some kind of odd caching perhaps? Investigation required.

@aaronadamsCA
Copy link
Author
aaronadamsCA commented Oct 25, 2022 •
edited
Loading

Yeah, I went down a whole rabbit hole of "is it somehow not finding tsconfig.json" - but the debug output seemed fine.

Eventually I realized the rules were only failing in certain files, but working fine in others. Eventually I managed to isolate the issue to files importing from @mui/joy (but again, not all of them).

I have wondered if the (possibly extraneous?) package.json file at node_modules/@mui/joy/styles/package.json could be somehow confusing the single run logic. It's the only thing that seems unusual to me. There are similar nested package.json files in most first-level directories in that package, e.g. https://unpkg.com/@mui/joy@5.0.0-alpha.46/Button/package.json.

@JoshuaKGoldberg
Copy link
Member

If you rm that package.json and the other odd nested ones just after installing in CI, does the error go away?

@aaronadamsCA
Copy link
Author

Ah, great question. The answer is no:

https://github.com/aaronadamsCA/typescript-eslint-issue-5136/actions/runs/3322301096/jobs/5491127934

@bradzacher
Copy link
Member

I tried and it doesn't repro locally - so maybe something specific to the action environment?

https://github.com/aaronadamsCA/typescript-eslint-issue-5136/actions/runs/3322301096/jobs/5491127934#step:6:38

typescript-eslint:eslint-plugin:utils:types Found an "error" any type

That generally means that our parser was unable to resolve some type.
Currently we ignore all TS diagnostics (aka semantic TS checker errors) because asking TS to compute them can take like 50ms per file (which is obviously too slow for ESLint).
The flag I added in the below PR should make the parser dump them out.

@aaronadamsCA please approve the actions on aaronadamsCA/typescript-eslint-issue-5136#3 so we can see the logs

@bradzacher bradzacher added awaiting response Issues waiting for a reply from the OP or another party and removed triage Waiting for team members to take a look labels Oct 25, 2022
@aaronadamsCA
Copy link
Author
aaronadamsCA commented Oct 25, 2022 •
edited
Loading

You should be good to go.

Note that at one point I was also reproducing locally - not sure what changed there. I can dig in further if it's at all helpful.

@bradzacher
Copy link
Member

Oof. Investigation blocked by #5887

@bradzacher
Copy link
Member

okay I've figured it out! PR soon

@bradzacher bradzacher added accepting prs Go ahead, send a pull request that resolves this issue and removed awaiting response Issues waiting for a reply from the OP or another party labels Oct 26, 2022
@bradzacher bradzacher mentioned this issue Oct 26, 2022
Merged
3 tasks
@aaronadamsCA
Copy link
Author

Awesome. I am also assuming this was a race condition, which would explain why the issue seemed to randomly disappear only to return again later. That part was driving me especially crazy.

I'll be glad to have this sorted and get back some linting speed, thank you! 🙌

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 17, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
accepting prs Go ahead, send a pull request that resolves this issue bug Something isn't working
Projects
None yet
Milestone
No milestone
3 participants
@aaronadamsCA @JoshuaKGoldberg @bradzacher
0