feat(eslint-plugin): sort members alphabetically

packages/eslint-plugin/docs/rules/member-ordering.md

@@ -7,16 +7,21 @@ A consistent ordering of fields, methods and constructors can make interfaces, t
 This rule aims to standardize the way class declarations, class expressions, interfaces and type literals are structured and ordered.
 
 ### Grouping and sorting member groups
+
 It allows to group members by their type (e.g. `public-static-field`, `protected-static-field`, `private-static-field`, `public-instance-field`, ...) and enforce a certain order for these groups. By default, their order is the same inside `classes`, `classExpressions`, `interfaces` and `typeLiterals` (note: not all member types apply to `interfaces` and `typeLiterals`). It is possible to define the order for any of those individually or to change the default order for all of them by setting the `default` option.
 
 ### Sorting members
+
 Besides grouping the members and sorting their groups, this rule also allows to sort the members themselves. You have 2 options: Sort all of them while ignoring their type or sort them inside of the member types (e.g. sort all fields in an interface alphabetically).
 
 ## Options
+
 These options allow to specify how to group the members and sort their groups.
+
 ```ts
 {
   default?: Array<MemberType> | never
+
   classes?: Array<MemberType> | never
   classExpressions?: Array<MemberType> | never
 
@@ -26,14 +31,16 @@ These options allow to specify how to group the members and sort their groups.
 ```
 
 If you want to enforce an alphabetic order, you have to use this form
+
 ```ts
 {
-  default?: { memberTypes?: Array<MemberType>, order?: 'alphabetically' } | never
-  classes?: { memberTypes?: Array<MemberType>, order?: 'alphabetically' } | never
-  classExpressions?: { memberTypes?: Array<MemberType>, order?: 'alphabetically' } | never
+  default?: Array<MemberType> | { memberTypes?: Array<MemberType> | 'never', order?: 'alphabetically' }
 
-  interfaces?: { memberTypes?: Array<MemberType>, order?: 'alphabetically' } | never
-  typeLiterals?: { memberTypes?: Array<MemberType>, order?: 'alphabetically' } | never
+  classes?: Array<MemberType> | { memberTypes?: Array<MemberType> | 'never', order?: 'alphabetically' }
+  classExpressions?: Array<MemberType> | { memberTypes?: Array<MemberType> | 'never', order?: 'alphabetically' }
+
+  interfaces?: ['field' | 'method' | 'constructor'] | { memberTypes?: Array<MemberType> | 'never', order?: 'alphabetically' }
+  typeLiterals?: ['field' | 'method' | 'constructor'] | { memberTypes?: Array<MemberType> | 'never', order?: 'alphabetically' }
 }
 ```
 
@@ -657,6 +664,75 @@ type Foo = {
 };
 ```
 
+### Sorting alphabetically within member groups
+
+It is possible to sort all members within a group alphabetically.
+
+#### Configuration: `{ default: { order: 'alphabetically' } }`
+
+This will apply the default order (see above) and enforce an alphabetic order within each group.
+
+##### Incorrect examples
+
+```ts
+interface Foo {
+  a: x;
+  b: x;
+  c: x;
+
+  a(): void;
+  b(): void;
+  c(): void;
+
+  [a: string]: number;
+  (): Baz;
+
+  new (): Bar;
+}
+```
+
+Note: Wrong group order for `new () : Bar`.
+
+```ts
+interface Foo {
+  a: x;
+  b: x;
+  c: x;
+
+  new (): Bar;
+
+  c(): void;
+  b(): void;
+  a(): void;
+
+  [a: string]: number;
+  (): Baz;
+}
+```
+
+Note: Wrong alphabetic order (should be `a(): void` --> `b(): void` --> `c(): void`).
+
+### Sorting alphabetically while ignoring member groups
+
+It is also possible to sort all members and ignore the member groups completely.
+
+#### Configuration: `{ default: { memberTypes: 'never', order: 'alphabetically' } }`
+
+##### Incorrect example
+
+```ts
+interface Foo {
+  b(): void;
+  a: b;
+
+  [a: string]: number; // Order doesn't matter (no sortable identifier)
+  new (): Bar; // Order doesn't matter (no sortable identifier)
+  (): Baz; // Order doesn't matter (no sortable identifier)
+}
+```
+
+Note: Wrong alphabetic order `b(): void` should come after `a: b`.
+
 ## When Not To Use It
 
 If you don't care about the general structure of your classes and interfaces, then you will not need this rule.