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
"no-cycle" affecting type resolution between monorepo packages #2496
"no-cycle" affecting type resolution between monorepo packages #2496
Comments
Setting aside that "require-await" is a harmful rule that should never be enabled, I can't conceive of why one rule being enabled would possibly impact a different one - especially in another plugin. eslint actively prevents rules from affecting each other. Which version of the TS eslint resolver are you using? |
Right, those rules don't seem that great, I'll probably remove both. Sorry forgot to include: The reason that I added the TS resolver was to use |
Right, that all makes sense. cc @bradzacher - any hints as to why one rule would impact another? |
I'd need a concrete reproduction case. @toerndev can you create an isolated GH repo with the minimal setup required to repro this issue? |
@ljharb separate and unrelated to the issue, just as an FYI. |
@bradzacher that's helpful, but it's perfectly valid to have an async function that does not return a promise and does not use |
@bradzacher I peeled off as much as I could: toerndev/reproduce-eslint-issue |
FYI - the fix has been released in v5.42.0 of the @typescript-eslint tooling. So this issue can now be closed! |
Problem: I get additional errors from
@typescript-eslint/require-await
and@typescript-eslint/restrict-plus-operands
after activatingimport/no-cycle
.Out of these "extra" errors, some seem legit:
a.b + c // a can actually be undefined here so "restrict-plus-operands" makes sense
...while in other cases, TS normally infers the
number
type but now suddenly requires more explicit/direct types for variables.performance.now()
isn't accepted as anumber
whenno-cycle
is on.useState(0)
can normally inferred to be a number, but now needs<number>
.maybeUndefined?.myNumber ?? 0
is no longer understood to be a numberetc.
It's as if using a much older version of typescript.
These errors also only appear when invoking eslint on multiple monorepo packages at once, with some files that import from the other package.
As for
require-await
, the following file with no imports only has an error when also runningno-cycle
:Minimal setup to reproduce:
The
tsconfig.json
in each package:Adding
settings['import/resolver'].node.paths
to match the baseUrl changes the number of errors a little bit.The text was updated successfully, but these errors were encountered: