Suggestion: noInferredAny #39633

Activity

1. Ryan Cavanaugh (RyanCavanaugh)

   added

   Needs ProposalThis issue needs a plan that clarifies the finer details of how it could be implemented.This issue needs a plan that clarifies the finer details of how it could be implemented.

   SuggestionAn idea for TypeScriptAn idea for TypeScript

   on Jul 17, 2020
2. RyanCavanaugh commented on Jul 17, 2020

   

   Ryan Cavanaugh (RyanCavanaugh)

   on Jul 17, 2020

   Member

   More actions

   So consider something like

   // Elsewhere
   declare function fn<T = string>(): T extends "foo" ? { p: boolean } : { m: any };
   
   const k = fn();

   Is this an "inferred" any because k.m has type any? If so, how does TypeScript perform an infinite examination of all potential properties (it can't)? If not, is the feature working? Does the access occur on k.m cause the error instead? Or on property access of k.m?

   Thinking about this in terms of only binding an inference to a top-level binding just misses a lot of cases. If you keep poking at this hornet's nest you end up with the proposed --strictAny, #24737. We can revisit that one again later, or if you have more concrete proposal here for exactly what would count as an error and a demonstration of how that would work beyond basic examples, that'd be interesting too
3. mprobst commented on Jul 20, 2020

   

   Martin Probst (mprobst)

   on Jul 20, 2020 via email

   ContributorAuthor

   More actions

   So consider something like // Elsewheredeclare function fn<T = string>(): T extends "foo" ? { p: boolean } : { m: any }; const k = fn(); Is this an "inferred" any because k.m has type any?

   I would say no: `k` is inferred to `{m: any}`, and `m` has been explicitly declared to be `any`. Now if you'd follow up with `const j = k.m;`, `j` would be an inferred any, and you'd get an error. I think you're right though, what I was thinking of sounds like a dupe of #24737. Thanks for the pointer, that's an interesting read.

   …
4. stefee commented on Sep 5, 2021

   

   Stef (stefee)

   on Sep 5, 2021

   Last edited by stefee

   More actions

   For anyone finding this now and wondering if there is a solution, you can use typescript-eslint with the following rules:

     "rules": {
       "@typescript-eslint/no-unsafe-argument": "error",
       "@typescript-eslint/no-unsafe-assignment": "error",
       "@typescript-eslint/no-unsafe-call": "error",
       "@typescript-eslint/no-unsafe-member-access": "error",
       "@typescript-eslint/no-unsafe-return": "error"
     }

   Links to the documentation for these rules can be found here: https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin#supported-rules

   You can also add these rules, plus some others, using the recommended-requiring-type-checking preset:

     "extends": [
       "eslint:recommended",
       "plugin:@typescript-eslint/recommended",
       "plugin:@typescript-eslint/recommended-requiring-type-checking",
     ]

   You must also add this to your eslint config to allow the eslint plugin find your ts project configuration which enables it to do type-checking:

     "parserOptions": {
       "project": "./tsconfig.json"
     },

   Here's the full docs for the parser config: https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/parser#configuration
5. osdiab commented on Dec 19, 2024

   

   Omar Diab (osdiab)

   on Dec 19, 2024

   More actions

   Stef (@stefee) 's solution from a few years ago works, though I would love if this were built into TypeScript instead of needing to use typescript-eslint for it, since it is extremely slow and makes many spurious errors in the editor when files change, like this: microsoft/vscode-eslint#1321

   I don't really care if any is being used in library code, but if in my own code I could have TypeScript throw an error basically identically to what Typescript ESLint does with the above set of rules; then that would be perfect for my use cases—so if that can act as a concrete proposal of what exactly counts as an error, and a demonstration of how it would work beyond specific examples, then I hope that remains interesting!