Allow the option to disable magic number warnings within arrays

[mulholo]

What rule do you want to change?
no-magic-numbers (source, docs)

Does this change cause the rule to produce more or fewer warnings?
Fewer (if enabled as option). No changes by default.

How will the change be implemented? (New option, new default behavior, etc.)?
I imagine this as an extra boolean option, e.g. ignoreArrayElements, that defaults to true (the current behaviour).

You could also specify a max array length. e.g. short arrays (which are more explicit) are ignore by the rule, long arrays are not.

Please provide some example code that this change will affect:

This is the code that made the need for the new option apparent:

  it('returns a number for numerical column', () => {
    // It is clear what these numbers are, yet they are producing an error
    const indexesOfNumericalCells = [12, 13]; // warning on this line ❌ 

    expect(
      stringValuesToNumbers(items)[indexesOfNumericalCells[0]]
    ).toEqual(expect.any(Number));

    expect(
      stringValuesToNumbers(items)[indexesOfNumericalCells[1]]
    ).toEqual(expect.any(Number));
  });

This scenario could be avoided by destructuring the array, but that feels inelegant at the moment. If you had a longer array of indexes that you wanted to loop over this would get even worse:

  it('returns a number for numerical column', () => {
    const indexesOfNumericalCells = [12, 13, 14, 15]; 

    indexesOfNumericalCells.forEach(index => {
      expect(stringValuesToNumbers(items)[index]).toEqual(expect.any(Number))
    });
  });

What does the rule currently do for this code?
Disallows ambiguously specified (magic) numbers from being written without a labelled variable. More specifically for this issue, the rule also raises a warning/error for magic numbers within arrays.

What will the rule do after it's changed?
Disable warnings for magic numbers found within arrays.

Are you willing to submit a pull request to implement this change?
Not unless absolutely necessary

[kaicataldo]

I think this is a very good use case for using inline eslint-disable comments rather than creating a brand new option for this pattern, but let's see what others on the team say.

[nzakas]

I agree, @kaicataldo

[eslint-deprecated]

Unfortunately, it looks like there wasn't enough interest from the team
or community to implement this change. While we wish we'd be able to
accommodate everyone's requests, we do need to prioritize. We've found
that issues failing to reach accepted status after 21 days tend to
never be accepted, and as such, we close those issues.
This doesn't mean the idea isn't interesting or useful, just that it's
not something the team can commit to.

Thanks for contributing to ESLint and we appreciate your understanding.