Feature: Ignore index signature while sorting types

[ntnyq]

What rule do you want to change?

sort-object-types, sort-interfaces

Describe the problem

I prefer the order like this:

• required
• optional
• index signature

but the plugin treats index signatures as a required property.

Maybe we can add an options to ignore index signature.

Or is there any options can already make this happen?

Code example

export type Foobar = {
  foo: string
  bar?: string
  [key: string]: any
}

Config is rule perfectionist/sort-object-types with groupKind: 'required-first'.

Additional comments

No response

Validations

• [X] Read the docs.
• [X] Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[hugop95]

@azat-io @OlivierZal I personally think that the groupKind option can be deprecated for a system similar to what exists in sort-classes and sort-modules, with

• selectors: index-signature, multiline, method, type (default selector).
• modifiers: optional, required.

This would allow users to:

• Reproduce the current behavior with required-first / optional-first with ['required-type', 'optional-type', 'unknown'] for example.
• Be flexible enough to handle a config like shown in this issue with ['required-type', 'optional-type', 'index-signature'].

The disadvantage is that it potentially does make the config a bit more verbose: it's easier to write groupKind: 'required-first' than a groups configuration, but this limits possibilities.

Let me know what you think!

[OlivierZal]

@hugop95, I would be in favor to migrate to the sort-classes / sort-modules system whenever it's possible: if you remember, at the beginning I proposed to use groupKind: optional-first/required-first for classes, but the system which has been chosen is both flexible and transparent. It might be overkill for some, given the small number of options for types/interfaces, but the resulted config shouldn't be more verbose though.