-
-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
ESLint incorrectly flagging variable as any #6314
Comments
Funny, I was just poking at a similar bug in t3-oss/create-t3-app#1036 (comment). I'd hoped microsoft/TypeScript#51914 would fix things but trying out |
Are you able to create a more distilled reproduction here? If you can help us by reducing this to a minimal reproduction in its own repo, we will be able to better prioritise this. I'd suggest forking the repo and deleting irrelevant files (non-eslint or ts config files, files not in the problem file's dependency tree) and irrelevant code from the problem file(s) until you distill it down completely. |
Worth noting that on the commit you linked - I can see there are dozens of unsafe any lint reports - not just in the one file.
so there's a lot of problems across all packages in your codebase. Which says to me that it's unlikely this is a bug, more likely this is a config issue instead. Distilling down a repro will help identify that. |
@bradzacher we've distilled it down to a simple repro containing only the relevant files and type definitions here: https://github.com/MuddCreates/hyperschedule/tree/typescript-eslint%236314-repro. The same lint warnings remain. Please let me know if that helps. |
I'm having a similar issue. I'm not sure if this helps but... export let validationRules: string[] | null = null;
let isRequired = validationRules?.includes('require');
// linting errors:
52:6 error Unsafe assignment of an `any` value @typescript-eslint/no-unsafe-assignment
52:19 error Unsafe call of an `any` typed value @typescript-eslint/no-unsafe-call However if I give export let validationRules: string[] = []; |
@jwerre I've replied on Discord, but cross-posting here: this is a TS feature (which usually causes issues for prototyping): CFA eagerly narrows |
I think I've just encountered this in our codebase...in our case the DOM In our code base, I can reproduce the problem with one tiny test file, called const problem: string = window
console.info(problem) If I compile this with tsc, I get the expected compiler error
Note how it's not really complaining about the type error in the assignment, but the use of an any-typed value. Running eslint with
This is the most interesting bit: Found an "error" any type. If I lint our entire project, I can see hundreds of these log lines, so clearly every lint error seems connected to this. I also did a session with a debugger, and managed to narrow down the problem to this code in const senderType = checker.getTypeAtLocation(esTreeNodeToTSNodeMap.get(senderNode)); In the case of the above If we continue a bit further, here's getTypeAtLocation: function (nodeIn) {
var node = ts.getParseTreeNode(nodeIn);
return node ? getTypeOfNode(node) : errorType;
}, The returned function checkIdentifier(node, checkMode) {
if (ts.isThisInTypeQuery(node)) {
return checkThisExpression(node);
}
var symbol = getResolvedSymbol(node);
if (symbol === unknownSymbol) {
return errorType;
} The last if statement is true, so this is where the error type is returned. It seems that Sorry for the wall of text 😅 I'm totally out of my league here, and don't have a good guess of where the problem ultimately is. And if it was a config problem, I don't understand why updating one random dependency would suddenly cause it and reverting the upgrade would fix it. My recommendation for others having the same issue is to try to use the |
@Gekkio ths problem is that whatever config you're using to lint your codebase with does not include the |
Note that typescript-eslint parser says in the debug logs I provided that the resolved libs were I can literally remove the dependency and its transitive dependencies from node_modules and it doesn't fix anything. Simply the original act of updating this unrelated dependency triggers the problem: ❯ npx eslint --ext .js,.jsx,.ts,.tsx src/lib-common/bug.ts
/home/joonas/projects/espoo/evaka/frontend/src/lib-common/bug.ts
2:1 error Unexpected console statement no-console
✖ 1 problem (1 error, 0 warnings) <-- no "any" lint errors
❯ yarn up react-spring
....(omitted for brevity)
➤ YN0000: Done with warnings in 3s 918ms
❯ npx eslint --ext .js,.jsx,.ts,.tsx src/lib-common/bug.ts
/home/joonas/projects/espoo/evaka/frontend/src/lib-common/bug.ts
1:7 error Unsafe assignment of an `any` value @typescript-eslint/no-unsafe-assignment
2:1 error Unexpected console statement no-console
✖ 2 problems (2 errors, 0 warnings) <-- "any" lint error appears
❯ rm -rf node_modules/react-spring node_modules/@react-spring
❯ npx eslint --ext .js,.jsx,.ts,.tsx src/lib-common/bug.ts
/home/joonas/projects/espoo/evaka/frontend/src/lib-common/bug.ts
1:7 error Unsafe assignment of an `any` value @typescript-eslint/no-unsafe-assignment
2:1 error Unexpected console statement no-console
✖ 2 problems (2 errors, 0 warnings) <-- "any" lint error remains Maybe I'm overthinking this, but it smells to me like some kind of ordering problem...like something traversing node_modules and being sensitive to the order. And when I update (and remove) this unrelated dependency, the file system returns something in a different order when directory contents are queried. |
I debugged our problem a bit more by using strace to see which files get opened by the node process. In the problem cases TS |
Ha, I wouldn't count this as spam at all. It's a super interesting investigation. And someone else is bound to have previously had this kind of situation. +1 to having the investigation on record & searchable in the issue tracker. Thanks @Gekkio! 🙌 |
Before You File a Bug Report Please Confirm You Have Done The Following...
Issue Description
When running Typescript ESLint on our code, we get
However, if you look at affected code, (GitHub permanent link)
Typescript ESLint thinks that the
section
variable is of typeany
, while it is explicitly defined to be of typeSection
. This cascaded into further warnings aboutunsafe-call
because it thinks some functions are undefined.I would expect no linter warning is triggered on this particular snippet of code.
Reproduction Repository Link
https://github.com/MuddCreates/hyperschedule/
Repro Steps
feafaaa599ab282af83babed490346a3c579ed08
yarn install
yarn lint
Versions
@typescript-eslint/eslint-plugin
5.48.0
@typescript-eslint/parser
5.48.0
TypeScript
4.9.4
ESLint
8.30.0
node
18.8.0
The text was updated successfully, but these errors were encountered: