I'm curious - are you able to use dom.iterable? I would think any es2022 target should support it, but I've never been totally certain on when you can and can't use dom.iterable/dom.asynciterable.

Forgot to include playground link with dom.iterable added to the config. It will get rid of the TS complaint for you 🙂 so the question is just whether you plan to run code in an environment that would support it

This rule is ported from tslint. It's one of the few rules that (a) doesn't handle TS specific syntax (b) doesn't use type information to check JS patterns. I think this rule ought to use type information because there could be many APIs that are indexable but not iterable—I've always been surprised that this rule false-positives so much but people have never complained.

there could be many APIs that are indexable but not iterable

Theoretically - yes.
In reality - no.

IIRC the rule looks for an indexer using the loop variable and the loop variable being incremented and the loop variable compared against a .length property.

So you need someone to build an API that exposes both contiguous numeric properties AND a .length property.
In reality this doesn't happen because ofc people just use an array.

The DOM pseudo-arrays are the only example I know of and that happens purely because legacy reasons.

So you need someone to build an API that exposes both contiguous numeric properties AND a .length property.

That's the definition of array-like objects. There are many non-array array-like objects, including typed arrays, DOM arrays, arguments, etc. It just happens that almost all array-like objects are also iterable because it's a really low-cost thing to do (you just add [Symbol.iterator]: Array.prototype.values). Nevertheless this rule in its current form just isn't safe, and as I've illustrated above its state is really odd.

It just happens that almost all array-like objects are also iterable because it's a really low-cost thing to do

Which is my point.
In theory it's a large hole - one could define an array-like without an iterator!

In reality
(a) people don't define APIs like that (they just define arrays because who the heck is insane enough to be inventing their own array-like data structure for their library?)
(b) the legacy array-like APIs are all (???) iterable.

So it's a teeny tiny hole that's very very unlikely to occur. Theoretically bad, Realistically fine.

My 2c

ACK that it's a weird rule to be in typescript-eslint. Seems like in its present implementation it really could/should just be in eslint core.

I'm always very sympathetic to edge-case correctness, but

1. this has the downside that it would require type info to fix
2. The existing bug has the benefit that it might make someone more likely to land on this issue or a docs page, where they may learn to add dom.iterable to the config, which is a better fix anyway (maybe we should add it to the doc page for this rule, too!).

So, I'm -0.1 on fixing this, unless we know of some examples in the wild that don't have Symbol.iterator and aren't fixed by dom.iterable.

I think it's okay to just document as a known limitation and move on given how rare the circumstances are. We can include the note about the lib as a solution for the DOM usecase.

OK fair. Not sure why this rule should remain in our plugin though🤷‍♂️

It's a stylistic concern - not a correctness one.
Additionally it does have the chance of false positives.
So it's unlikely that eslint core would want it.

So either we pass it off to a catch-all plugin like unicorn or we just keep the status quo. I don't see any real benefit to the user pain of moving it.

So it's unlikely that eslint core would want it.

Interestingly, we've had a bit more willingness than ESLint core to have non-formatting somewhat-mostly-stylistic rules (https://typescript-eslint.io/troubleshooting/formatting#eslint-core-and-formatting). prefer-for-of requires type checking and is generally applicable to all kinds of JavaScript projects.

We mirror the ESLint team's move away from formatting and stylistic rules. With the exception of bug fixes, no new formatting- or stylistic-related pull requests will be accepted into typescript-eslint.

A few references of other rules that could be for JavaScript in general, but need type information:

• Rule proposal: Loop style - .find, for-i, for-of, forEach #5710: similar to prefer-for-of, but more targeted to consistency
• Rule proposal: Prevent Object.values(...) usage with Map #6807: bug catching, not stylistic
• Rule proposal: Prefer Array.prototype.some() over Array.prototype.find() in boolean contexts #8378: arguably improves code semantics and is better usage of the built-in Array methods

Similar to #8792, we don't really have an ideal next place for prefer-for-of & co. - even if we were happy with the user pain of moving it.

I think it's okay to just document as a known limitation and move on given how rare the circumstances are. We can include the note about the lib as a solution for the DOM usecase.

👍 Accepting PRs as a documentation issue.