My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.

https://github.com/WebbyLab/eslint-plugin-more/blob/master/docs/no-filter-instead-of-find.md

Why this needs the type checker:

interface JerkCode<T> {
  filter(predicate: (item: T) => boolean): JerkCode<T>;
}

declare const jerkCode: JerkCode<string>;

jerkCode.filter(item => item === "aha");

(making this explicit in case future folks ask)

I guess there should ideally also be a check to see if the filter function does a side-effect, in which case the change will affect the current behavior.

I guess there should ideally also be a check to see if the filter function does a side-effect

We can do that once we solve the halting problem 😄.
As long as it's not autofixing the code then reporting on that sort of code isn't bad.
Though TBH a side-effect in a .filter is filthy code and I want to break it to teach that person a lesson.

We can do that once we solve the halting problem 😄.

Good luck, I'm looking forward to the results 😄

Though TBH a side-effect in a .filter is filthy code and I want to break it to teach that person a lesson.

I agree it is bad because it is unexpected. But I don't know about actively wanting to break it 😅
I do agree that not having an autofix would solve the problem. A suggestion would be possible (with a warning about side-effects ideally?), but autofix would be bad because of how ESLint applies all fixes without a chance to review them.

Apart from that, I agree with the proposed rule (it's something I'd like for Elm as well but find is not a standard function unfortunately).

The current title I think has them the wrong way around:

Rule proposal: Preferring .filter(...) over .find(...)[0]

Consider updating to:

Rule proposal: Preferring .find(...) over .filter(...)[0]

Is this already covered by https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/prefer-array-find.md?

See earlier comment - #6886 (comment)
The question is whether or not a type-aware rule should be created.

We have existing precedent with https://typescript-eslint.io/rules/prefer-includes, https://typescript-eslint.io/rules/prefer-regexp-exec, https://typescript-eslint.io/rules/prefer-string-starts-ends-with.

Oh and fun fact, https://sourcegraph.com/search?q=context:global+/filter.*%5C%29%5C%5B0%5C%5D/&patternType=standard&sm=1&groupBy=repo shows quite a few examples of people doing the .filter(...)[0] approach in the wild. Nifty!

I have a related request: I think you should prefer some over either filter[0] or find if the return value is only used in a Boolean context!

Whoo that's a complex one 😄. I don't know if it'd be easily feasible to get into this rule... maybe a good followup? Not sure 🤔

I have a related request: I think you should prefer some over either filter[0] or find if the return value is only used in a Boolean context!

I wonder whether this ought to just be a whole separate rule. I could certainly try to include it as an option for the fix for .filter(...)[0], but then existing code like

if ([1, 2, 3].find(x > 1)) {
}

would not get flagged. So maybe there should just be another rule entirely to prefer .some over .find in boolean contexts. I guess the drawback would be that if this rule just rewrites .filter(...)[0] -> .find(...) no matter what, then that will mean a second pass will be necessary to additionally fix the new rule.

Overall it seems like that rule would have quite a bit more complexity than makes sense just to add as a suggestion for this rule, since we'd have to start asking what we want done with

if ([-1, 0, 1].find(x => x === 0)) {
    // doesn't execute; not the same as [-1, 0 , 1].some(x => x === 0)
}

Thoughts?