[no-unsafe-assignment] [no-unsafe-call] [no-unsafe-return] Improve user experience when the “real” issue is caught by TypeScript #2665
Comments
|
This is not really feasible to solve. TypeScript doesn't tell us that this thing resolves to nothing - instead it just tells us its type is The In order to figure out if an Computing the diagnostics can take an average of 50ms per file. That might not sound like much, but that adds up to 1 second per 20 files! Across an entire project this kills lint times (I learned this the hard way with the |
|
Sad to hear! TypeScript + ESLint in VSCode is such a super nice way to write code. It’s a shame that they don’t feel more integrated, especially in the editor (on the command line one can just run On the same topic: microsoft/vscode-eslint#1087. Is there any heuristic we could use to catch maybe 80% of the cases? For example, for Alternatively, would it be possible to talk to the TypeScript developers and ask them to return better data? Sounds reasonable to be able to differentiate between “error any” and “actual any”. |
|
Yeah unfortunately there's a small issue with how IDEs are designed now a days. Everything is an extension, and everything is separate. TS support is provided using (an inbuilt) extension. ESLint support is provided using (a 3rd party) extension. In an ideal world we would be able to talk to the TS language server that's providing types to the IDE, and build on top of it to save time and effort. But alas... That's not how it works (for various reasons like security). There is actually some work that someone else has done that might be of interest to you. It integrates eslint into typescript as a language server plugin. So why not promote this as the defacto way to use our tooling? Mainly because the ESLint extension is more prevelant and requires less config to get working.
The problem is that we don't know if you were referring to a global thing that doesn't exist because you've misconfigured something. There's probably something we can do, but my intuition makes me thing that it's likely that most (if not all) cases of false-po 8000 sitives have a similar misconfiguration possibility. With everything to do with linting, I always favor false-positives to false-negatives. False positives are noise you can ignore (annoying people is bad sure, but better than...). False negatives unknowingly introduce bugs and erode the user's trust in the ecosystem. It's currently possible for us to detect error There's probably more TS could report here without requiring us to reach for diagnostics, but I just haven't invested too much time into thinking about it. It'd need some thinking to provide a decent proposal to the TS team, and possibly more time to implement into TS itself. Time is something I don't have enough of unfortunately 😅 |
|
Thanks for the detailed reply! I think the “correct” solution to this problem is more I’m currently diving into the TypeScript issue tracker to see if something like this has been discussed before. |
|
I think we’re doomed:
Feel free to close the issue if it helps maintenance on this repo, or keep it open if you feel like it’s a legit thing to improve although unlikely to be fixed. |
|
Because of https://gist.github.com/RyanCavanaugh/f80f9ddc50d45c4d76e7c4101efada28 it's is actually quite likely to be added. There is microsoft/TypeScript#40178, though for now it covers only property access. |
|
As there's nothing we can strictly action in this project right now - I'm going to close this. |
Repro
{ "rules": { "@typescript-eslint/no-unsafe-assignment": "error", "@typescript-eslint/no-unsafe-call": "error", "@typescript-eslint/no-unsafe-return": "error", } }{ "compilerOptions": { "allowSyntheticDefaultImports": true, "forceConsistentCasingInFileNames": true, "importsNotUsedAsValues": "error", "isolatedModules": true, "module": "CommonJS", "moduleResolution": "node", "noFallthroughCasesInSwitch": true, "noImplicitReturns": true, "noUnusedLocals": true, "noUnusedParameters": true, "skipLibCheck": true, "strict": true, "target": "ES2019", "lib": [ "ES2019", ], "outDir": "build" } }Expected Result
const tool =line: I only want TypeScript to say thatfindMatchingToolisn’t defined.returnline: I only want TypeScript to say thatgetScoreisn’t defined.Actual Result
ESLint:
TypeScript:
The TypeScript errors are enough! Once they are fixed the
no-unsafe-*errors are likely fixed as well!Additional Info
Although I showed CLI output above for brevity, my issue is about the experience in VSCode (or any editor with ESLint support really).
I often write code that calls nonexistent functions. Once I’ve sketched out the code a bit I go back and try to actually implement those functions. I do this by jumping to the next error – sometimes I end up fixing something else, like a typo, and eventually I come across one of those functions that don’t exist yet. At first I might not remember that the function does not exist, so I read the error messages to find out what’s wrong. That can be a bit noisy. The real error is that the function does not exist, but it gets lost in a sea of “unsafe any” errors.
When I see those “unsafe any” errors I think like “Duh, of course they’d be
any, the function does not even exist”.I think it would be awesome if the
no-unsafe-*rules could avoid causing errors if there’s another TypeScript error causing them in the first place!My goal is to improve the editing experience by reducing unnecessary errors/warnings that clutter the editor. If you have a better idea on how to do that I’d be all ears!
Possibly related: #2164
Versions
@typescript-eslint/eslint-plugin4.4.0@typescript-eslint/parser4.4.0TypeScript4.0.3ESLint7.11.0node14.10.1The text was updated successfully, but these errors were encountered: