Rule proposal: Ban 'in' operator for arrays

[ZhangYiJiang]

Before You File a Proposal Please Confirm You Have Done The Following...

• I have searched for related issues and found none that match my proposal.
• I have searched the current rule list and found no rules that match my proposal.
• I have read the FAQ and my problem is not listed.

My proposal is suitable for this project

• My proposal specifically checks TypeScript syntax, or it proposes a check that requires type information to be accurate.
• My proposal is not a "formatting rule"; meaning it does not just enforce how code is formatted (whitespace, brace placement, etc).
• I believe my proposal would be useful to the broader TypeScript community (meaning it is not a niche proposal).

Description

Checking for array membership using in is a common new JS developer mistake - it looks like it should work but it does not since in checks for properties, and array values are not properties.

Fail Cases

const arr = ['a', 'b', 'c'];
const inArray = 'a' in arr;

Pass Cases

const arr = ['a', 'b', 'c'];
const inArray = arr.includes('a');

Additional Info

There is a very similar https://typescript-eslint.io/rules/no-for-in-array rule for for-in loops specifically

[JoshuaKGoldberg]

SGTM! As stated & with no-for-in-array, this will have to be a typed rule, to know whether a value is an array.

[juank1809]

I'd like to work on this issue! though it will take me some time.

[mahdi-farnia]

✅ Just needs a review

[bradzacher]

@JoshuaKGoldberg i wonder if we should merge this with #5677

It seems like they're doing the same thing, except #5677 covers more cases.

[mahdi-farnia]

@JoshuaKGoldberg i wonder if we should merge this with #5677

It seems like they're doing the same thing, except #5677 covers more cases.

I agree, but i think it should be too hard.
In JavaScript everything is an object and has proprties (except null and undefined) that those property has other properties... (prototype chaining)
What is the standard way to detect indexables?

[bradzacher]

@mahdi-farnia by using types! All of the relevant information is available on the types.

You can play around in https://ts-ast-viewer.com to get a feel for how different cases might look.

Grep our codebase fir getProp and you'll find some property lookup examples.

Your code is a good special case message to start with - but we should do more than just arrays if we can!

[mahdi-farnia]

@bradzacher I've done exploring and working with astexplorer.
I'll check that link too!

But my question remains: which types are indexable?
Arrays & PlainObjects only?

[bradzacher]

Any type with an index signature is indexable.

Eg

type T = { [k: string]: number}

But we should still ensure we disallow string likes and arrays

[mahdi-farnia]

@bradzacher
Typescript already raises error for string type. (String indexes are readonly)
But distinguish types that have index signature is impossible (isn't it?)

As i said everything in JavaScript is a pair of keys and values: Record<PropertyKey, any>
In my opinion these scenarios are possible:

1. Ban delete at all
2. Disallow delete for index of type numbers for arrays (better)

[JoshuaKGoldberg]

But distinguish types that have index signature is impossible (isn't it?)

You can use the type checker for this. Just playing around on my end, I do see an '__index' type declared in the symbol for let temp: { [i: string]: string } = {}'s backing type. Array.from(type.symbol.members[0]). You'll have to play with a bit on your end.

[JoshuaKGoldberg]

@JoshuaKGoldberg i wonder if we should merge this with #5677
It seems like they're doing the same thing, except #5677 covers more cases.

Agreed, good point. no-misused-in would cover this case anyway.

Closing this as a dup. Thanks for the discussion all!