Rule proposal: typescript tuples should use [] and arrays .at() for accessing members

[nicolassanmar]

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

There should be a rule that allows enforcing arrays to use array.at(0) to access it's members, while allowing tuples to use tuple[0] (bracket notation) to do so.
This is useful since using bracket notation on an array of type T can return undefined if the number is out of range, but the type that typescript returns is only T.
Using .at() correctly informs the developer about this.

This is not true on tuples, where given a tuple of type [X, Y] accessing the parameters with bracket notation should return something of type X or Y.

Currently there is no rule to enforce this, and I could not find a way to implement this as a custom rule either.

Fail Cases

const array: number[] = [1,2]
array[3] // we should not do this since it could not exist on the element

Pass Cases

const tuple: [number,number] = [1,2]
tuple[1] // we know this exists due to the type of the tuple

const array: number[] = [1,2]
array.at(3) // this can return undefined, so the user gets the correct information

Additional Info

No response

[bradzacher]

The difficult thing about this is that .at still only has pretty recent support - less than 2 years in major browsers. Node 14 doesn't support it and it's still LTS.

Additionally there is a TS compiler option which will make array access safe - noUncheckedIndexAccess. In fact it'll be safer than .at because TS can track the result of checking arr[I] and narrow the type - but TS cannot narrow the type of arr.at(i) as it is a function call.

playground example

---

That being said - we do have #6401 and the associated PR #6411 which are on the track to doing this style of enforcement.

I'm not sure if we would want to take that the whole way to always using .at though. Cc @JoshuaKGoldberg

[JoshuaKGoldberg]

Yeah I don't think we should implement this in typescript-eslint core. It's a very particular practice that is mirrored by a TypeScript compiler option - and not (yet?) adopted by the community.

We (linters) have been hurt in the past by implementing rules that enforce not-seen-as-best-by-everyone(-yet?) best practices not adopted by the community. People get real mad if they think we're trying to enforce some seemingly arbitrary code style on them... This one certainly couldn't be enabled in a recommended rule set, and even if we provide it as an option it's unclear yet whether many users would want it.

I'd love to see it implemented in a shared ESLint plugin using APIs described in our custom rule docs. Please do! 😄

[nicolassanmar]

@bradzacher Thanks! I did not know about noUncheckedIndexedAccess and it does solve the issue I have.

@JoshuaKGoldberg I agree with your points. Also, considering that we have the noUncheckedIndexedAccess, this rule will not make sense.

Thank you both!