[no-explicit-any] False positive for type predicates #1048
Comments
|
There's no false positive here. What happens if I pass I haven't spent enough time around narrowing interface Foo {
bar: number;
}
export function isObject(x: unknown): x is Record<string, unknown> {
return typeof x === 'object' && x != null;
}
export function isFoo(x: unknown): x is Foo {
if (!isObject(x)) {
return false;
}
if (typeof x.bar !== 'number') {
return false;
}
return true;
}Also - this type guard still isn't completely safe, because you will potentially allow more properties than In strictly typed code, you shouldn't ever really have to reach for |
Yikes, you're completely right, |
|
I will generally write the original example as interface Foo { bar: number }
export const isFoo = (x: any): x is Foo =>
typeof x === 'object' &&
x && // or often x !== null if I want to be more explicit
typeof x.bar === 'number'That's the only time I use And just to be clear, I only do this with type guards for object types, but object types constitute 99% of all the custom type guards I write. If I agree in principle with this lint rule. I still think this is a valid rule, but not everyone will want to apply it in typeguards. I felt like the conversation around the original example got kinda muddied by the error in it even though it showed a great argument against using
One last thing, and this is important. In fact, if you return |
|
I agree that using Though I would argue that having an expression-level IMO, it's not a good idea to add an option to this rule to allow an any in a specific case, unless it's required to make sure that typescript compiles. I wouldn't say it's necessarily less sound, it's just something to be aware of, and it's something you probably need to be handling via 3.7 assertion functions instead of pure type guards. For example, I've seen a lot of code which assumes exact objects and throws on unexpected properties (code that handles configuration objects is a good example of this). I do wish TS would add exact objects though. They're one of the few things I really love about flow. |
|
Yeah, totally agree on expression-level assert vs Pretty much agree with everything you're saying here. I hope/assume TS will keep improving around some of these pain points. |
Repro
{ "parser": "@typescript-eslint/parser", "extends": [ "plugin:@typescript-eslint/recommended" ] }Expected Result
No lint issues.
Actual Result
Additional Info
An
anytype should be allowed as a function parameter when writing a type predicate, as it is reasonable for the function to take ananyand narrow the type based on some condition inside the function. Typescript 3.7 is going to have type assertion functions, and those should probably also allow theanytype.Versions
@typescript-eslint/eslint-plugin2.3.2@typescript-eslint/parser2.3.2TypeScript3.6.3ESLint6.5.1node12.11.0npm6.11.3The text was updated successfully, but these errors were encountered: