使用 Typescript 时如何避免触发 eslint 的 for..in

Question

I currently use the TypeScript recommended approach to iterate over object's keys., like this:

    let key: keyof ExampleObject;
    for (key in exampleObject) {
      // do some work with exampleObject[key];
    }

In my current project Eslint complains about using for..in construct like this:

for..in loops iterate over the entire prototype chain, which is virtually never what you want. Use Object.{keys,values,entries}, and iterate over the resulting array      no-restricted-syntax
The body of a for-in should be wrapped in an if statement to filter unwanted properties from the prototype                                                                 guard-for-in

I have seen several similar questions and answers for JavaScript eg using Object.keys(...) but TypeScript doesn't like this approach too and it loses some of the typesafety.

Is there a way to avoid triggering Eslint rules while still adhering to the TypeScript best practices? I know I can just turn off the designated rules but I hope there is a less 'hacky' way

Answer 1

Eslint is complaining for an extremely valid reason, and you should basically never use for...in unless you explicitly want to walk the prototype chain, which you basically never do.

As for the rest...

TypeScript doesn't like this approach too and it loses some of the typesafety.

Yeah. Your problem isn't Object.keys , your problem is that runtime reflection and compile-time type safety are natural enemies in the wild. So there isn't a 'clean' way to do this, you are saying "give me all of the properties of this object at runtime" which can't be safely known at compile-time, and changing the mechanism by which you ask for that isn't going to fix the fundamental underlying issue.

You have a few options for dealing with this.

1. Change your approach. Do you really need to iterate over all the keys of that object? All of them? Or can you use a compile-time const array of known keys?
2. Use compile-time legible runtime checks like instanceof , typeof , the in operator, etc to narrow the type.
3. Accept the loss of type-safety and use casts to satisfy the compiler.