Proposal: minimum number of keys option for sort-keys

[csantos42]

Background

My team is undergoing an exercise where we re-evaluate our enabled lint rules to identify any pain points.

The most unpopular so far is sort-keys, as the value of this rule is only apparent for object literals with a large number of keys (the extreme case being an object containing something like the dependency list in package.json, where it's extremely useful that the keys are sorted).

For objects containing 2 or 3 keys, it becomes more of a chore, especially considering the fact that this rule is not auto-fixable by design.

---

What rule do you want to change?
sort-keys

Does this change cause the rule to produce more or fewer warnings?
Fewer when the option is set as it would allow the user to provide a minimum number of keys that an object literal should have in order for this rule to take effect. By default, the minimum number of keys would be 2.

How will the change be implemented? (New option, new default behavior, etc.)?
New option -- I'm thinking minKeys is consistent with the naming of other options throughout ESLint, but happy to hear other suggestions.

Please provide some example code that this change will affect:

/* eslint sort-keys: ["error", { minKeys: 5 }] */

const styles = {
  position: 'relative',
  color: 'blue'
};

const styles2 = {
  fontSize: 16,
  position: 'relative',
  color: 'blue',
  zIndex: 10,
  display: 'block',
};

What does the rule currently do for this code?
ESLint produces 3 errors, one error for the property ordering of styles and two errors for the property ordering of styles2.

What will the rule do after it's changed?
With minKeys set to 5, only styles2 will produce lint errors, so there will be a total of 2 lint errors.

Are you willing to submit a pull request to implement this change?
Yes, happy to open a PR if the proposal reaches consensus

[platinumazure]

This seems reasonable. I'll support. 👍

[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.

[dcastil]

I'd like to have this implemented, too! 😊 Waiting for the feature to be merged!

[kaicataldo]

I'll champion this. I think this is worth another look, given the large support from the team (3 thumbs up here and 1 on the corresponding PR) and the existence of the PR.