3 ms·
This particular example is close to my heart: the definition files for things like JSON.parse() were written before the "unknown" type was introduced as an alte
by kipple 6y ago
This particular example is close to my heart: the definition files for things like JSON.parse() were written before the "unknown" type was introduced as an alternative to "any"
And because this "any" is coming from an external definition file, it can't be caught by tsc's --noImplicitAny nor eslint's no-explicit-any
Those two rules allow us to protect us from our own code, but not external definitions/libraries. Relevant GitHub issue here — https://github.com/microsoft/TypeScript/issues/26188 https://github.com/microsoft/TypeScript/issues/26188
- kipple 6y agoLooks like eslint is working on a new set of rules that would help with these currently-unprotected any cases: https://github.com/typescript-eslint/typescript-eslint/issues/791 https://github.com/typescript-eslint/typescript-eslint/issue... > Create a rule which uses type information to determine when you're inadvertently breaking type safety by using an any, potentially without knowing. > Often libraries (or even the typescript defs themselves) can have weak(/lazy) types which return any. If you're not careful, you can inadvertently introduce anys within your codebase, leading to bugs that aren't caught by the compiler.