-
-
Notifications
You must be signed in to change notification settings - Fork 2.8k
Missing types when using project references and single run inference (allowAutomaticSingleRunInference) #3851
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.
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
Comments
We don't consume project references from this project - we never have - #2094. In a nutshell - when in single-run mode we do a different It looks like there's something internal to TS which means that:
In comparison the program created by
I'm not sure why they behave differently. As far as I can tell - this is likely related to your I won't have any bandwidth to look into this more sorry - happy to provide pointers if you'd like to dig in more. |
Thanks for taking a look at it. And sure, If you could provide some points of interest on the code that would be great for me to investigate. |
in a nutshell - the code follows this structure:
It's a little more complicated than that because we lazily compute everything, but that's it in a nutshell! It looks like for some reason TS's You might need to dig into the TS codebase a little to figure out if we're calling the API incorrectly, or if we're calling the |
Sadly, I think this is blocked on us being able to know whether ESLint is in fixer mode or not. I think that makes this issue both/partially-each:
🥲, as always. Someone please say something if there's a workaround we can go with! |
Well, the ESLint RFC was declined and no action has happened on that front since then (😞). But we would greatly benefit from being able to enable
Marking as |
Honestly I don't know what the issue is so I don't know what would fix it. There's a discrepancy somewhere between the two code paths that causes this. Someone just needs to answer the question of why the two return different paths. |
Ok! Following up on this: I now more strongly believe the project service ( I would love to know why the watch vs. non-watch programs go down different code paths. But given that the new project service resolves the issue and we don't actually support project references otherwise, I don't think we need to take a strong look at this. Closing as resolved. "parserOptions": {
"allowAutomaticSingleRunInference": true,
- "project": ["./packages/*/tsconfig.json"]
+ "EXPERIMENTAL_useProjectService": true
}, Someone please yell at me if we actually do have a need to investigate more deeply! 💜 |
Repro
We need a few files to reproduce this:
Reproduction is available here: https://github.com/gcangussu/typescript-eslint-bug-repro
Expected Result
Tests passing
We can see that it works with single run inference disabled with
Actual Result
Additional Info
It seems that with single run the project (tsconfig.json) is not being correctly taken into consideration. Checking the output of
packages/bar/src/public/utils.ts
shows that it is correctly typed. However, when it is imported from another package (foo), ts-eslint fails to find its type. Although, it works fine when imported from within the same package.I've kept only the rule
@typescript-eslint/no-unsafe-assignment
and runnpx eslint --ext=.ts --debug packages/foo/src/app.ts
.Output, click to expand
Relates to #3528
Versions
@typescript-eslint/typescript-estree
4.30.0
@typescript-eslint/eslint-plugin
4.30.0
@typescript-eslint/parser
4.30.0
TypeScript
4.4.2
node
14.17.6
The text was updated successfully, but these errors were encountered: