Add allowLineSeparatedGroups option to sort-keys rule

[nicogreenarry]

What rule do you want to change?
sort-keys

Does this change cause the rule to produce more or fewer warnings?
No changes, if the allowLineSeparatedGroups parameter is false or omitted, or fewer warnings if it is true.

How will the change be implemented? (New option, new default behavior, etc.)?
Add a new allowLineSeparatedGroups option, following the pattern of the tslint's object-literal-sort-keys rule.

Please provide some example code that this change will affect:

const person = {
  firstName: 'Nico',
  lastName: 'Greenarry',

  hobbies: ['cats', 'dodgeball', 'potlucks'],
};

What does the rule currently do for this code?

ESLint: Expected object keys to be in ascending order. 'hobbies' should be before 'lastName'. (sort-keys)

What will the rule do after it's changed?
If the allowLineSeparatedGroups option is true, then there would be no eslint exception.

Are you willing to submit a pull request to implement this change?
Yes. I haven't looked at the eslint codebase before, so I expect there to be a learning curve, but I'm willing to figure out how to implement it properly.

[nicogreenarry]

I see that this option is specifically mentioned in the TSLint Migration Guide.

If this functionality will be completed in due time, then feel free to close this issue. But if it hasn't yet been decided whether to add this option, then consider this my petition to add it!

[mdjermanovic]

I support this proposal 👍

It hasn't been decided yet. I think this is the same as #12275 which didn't reach consensus at the time so the issue was closed, but maybe it will be different this time.

This looks to me like a reasonable enhancement, useful to allow for grouping different kinds of properties (which isn't supported by this rule), e.g.:

/*eslint sort-keys: "error"*/

const obj = {
  a: 1,
  b: 2, 
  c: 3,
  
  bar() {}, // error: 'bar' should be before 'c'
  foo() {}
}

[kaicataldo]

I support this, though I'm not convinced about the ignore-blank-lines option name. To me, it currently is ignoring blank lines, and this option would make it account for them. Would an option called groups be clear enough? Or lineSeparatedGroups?

[nicogreenarry]

I see your point about the name. If there isn't a convention (explicit or otherwise) against long-ish option names, I'd prefer something like lineSeparatedGroups or allowLineSeparatedGroups for clarity.

[g-plane]

Do we need a champion for this change?

[kaicataldo]

@nicogreenarry In recent times I think we've trended towards longer, more explicit option names :) Do you mind updating the proposal with allowLineSeparatedGroups?

@g-plane I'll champion. We just need one more supporter.

[anikethsaha]

Marked this as accepted as this has a champion and supporters.

[JJoGeon]

Agree with the proposal too.
@nicogreenarry If you don't mind, can I work on this issue?
I'm new here and I'm looking for something to contribute. 😄

[nicogreenarry]

@JJoGeon yes, by all means!