prefer-destructuring maxIndex option

What rule do you want to change? prefer-destructuring

Does this change cause the rule to produce more or fewer warnings? Fewer

How will the change be implemented? (New option, new default behavior, etc.)? New option to add to second options with enforceForRenamedProperties, something like maxIndex.

Please provide some example code that this change will affect: When accessing indexes on arrays that are relatively large (>10), there is a point of diminishing return where destructuring the array becomes more and more impractical.

This idea is mentioned in the docs here on the extreme side where the index is 100. But there is no recourse for this scenario other than to ignore or disable the rule. But with this change, people will be able to address this scenario to their liking.

const data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12];
const previous = data[7];
const current = data[8];
const next = data[9];

which fixing this would look something like…

const data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12];
const [,,,,,, previous, current, next] = data;

This to me is nice because of the chained index values but the preceding commas required to access large indices can get unruly and negate readability, on the order of 20 or 50 let alone 100.

What does the rule currently do for this code?

const data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12];
const previous = data[7]; // <-- errors on prefer-destructuring
const current = data[8]; // <-- errors on prefer-destructuring
const next = data[9]; // <-- errors on prefer-destructuring

What will the rule do after it’s changed? For a example rule configuration like this

{
  "rules": {
    "prefer-destructuring": ["error", {
      "array": true,
      "object": true
    }, {
      "maxIndex": 8
    }]
  }
}

const data = [1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12];
const previous = data[7]; // <-- error becasue 7 <= 8
const current = data[8]; // <-- error becasue 8 <= 8
const next = data[9]; // <-- no error because 9 > 8

Are you willing to submit a pull request to implement this change? Yes

[anikethsaha]

ahh, I see.

yea I will make an issue soon.

[kaicataldo]

We also have the ECMAScript 6 category, and so this could fit in either (it looks like we have other ES2015 syntax-specific rules in the stylistic section). For consistency and ease of understanding, I do think it would be better to get rid of the ECMAScript 6 category and move all those rules into the other, more descriptive categories. If you’d like to make an issue for that, feel free!