Improve type safety for array indexed access.

[seancolsen]

Problem

In this code, myNumber has type number, when its runtime value is actually undefined:

const numbers = [3, 5, 7, 11, 13];
const myNumber = numbers[100];

This can lead to bugs, (example).

Potential solutions

• (A) Enable noUncheckedIndexedAccess within tsconfig. This would likely lead to many type errors that we'd need to track down and fix.

• (B) Begin incrementally adopting a practice of using Array.at which has type safety by default. The only problem is that it hasn't been supported in Safari for that long, so we'd need to set up a polyfill for it.

• (C) Use type assertions to explicitly widen the result of an indexed access type. For example,

  const row = records[index] as RecordRow | undefined;

  I have been trying to do this whenever indexing an array. But it's easy to forget, and it also sacrifices type safety in the case the the type of the array actually changes due to some other refactor.

@pavish and @rajatvijay I'm curious to hear your thoughts on which of the above approaches you might be interested in adopting, if any.

[rajatvijay]

I prefer option A since this is the most reliable one and can be enforced easily.

Adopting option B will lead to more conventions, one more thing to check while reviewing the PR. Also might get out of hand when we get more outside PRs.

Having said that: Since option A will take a LONGER time to implement, how about having a convention for option B for now and deprecating it when option A lands?

[github-actions[bot]]

This issue has not been updated in 90 days and is being marked as stale.