Require a consistent member declaration order (member-ordering)
A consistent ordering of fields, methods and constructors can make interfaces, type literals, classes and class expressions easier to read, navigate and edit.
Rule Details
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 (e.g. a
, b
, c
, ...). You have 2 options: Sort all of them while ignoring their type or sort them while respecting their 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.
Sort groups, don't enforce member order: Use
memberTypes
Sort members, don't enforce group order: Use
order
Sort members within groups: Use
memberTypes
andorder
See below for the possible definitions of MemberType
.
Deprecated syntax
Note: There is a deprecated syntax to specify the member types as an array.
Member types (granular form)
There are multiple ways to specify the member types. The most explicit and granular form is the following:
Note: If you only specify some of the possible types, the non-specified ones can have any particular order. This means that they can be placed before, within or after the specified types and the linter won't complain about it.
Member group types (with accessibility, ignoring scope)
It is also possible to group member types by their accessibility (static
, instance
, abstract
), ignoring their scope.
Member group types (with accessibility and a decorator)
It is also possible to group methods or fields with a decorator separately, optionally specifying their accessibility.
Member group types (with scope, ignoring accessibility)
Another option is to group the member types by their scope (public
, protected
, private
), ignoring their accessibility.
Member group types (with scope and accessibility)
The third grouping option is to ignore both scope and accessibility.
Default configuration
The default configuration looks as follows:
Note: The default configuration contains member group types which contain other member types (see above). This is intentional to provide better error messages.
Note: By default, the members are not sorted. If you want to sort them alphabetically, you have to provide a custom configuration.
Examples
Custom default
configuration
default
configurationNote: The default
options are overwritten in these examples.
Configuration: { "default": ["signature", "method", "constructor", "field"] }
{ "default": ["signature", "method", "constructor", "field"] }
Incorrect examples
Note: Wrong order.
Note: Not all specified member types have to exist.
Note: Accessibility or scope are ignored with this configuration.
Note: Not all members have to be grouped to find rule violations.
Correct examples
Configuration: { "default": ["public-instance-method", "public-static-field"] }
{ "default": ["public-instance-method", "public-static-field"] }
Note: This configuration does not apply to interfaces/type literals as accessibility and scope are not part of interfaces/type literals.
Incorrect examples
Note: Public instance methods should come first before public static fields. Everything else can be placed anywhere.
Note: Public instance methods should come first before public static fields. Everything else can be placed anywhere.
Correct examples
Configuration: { "default": ["public-static-field", "static-field", "instance-field"] }
{ "default": ["public-static-field", "static-field", "instance-field"] }
Note: This configuration does not apply to interfaces/type literals as accessibility and scope are not part of interfaces/type literals.
Incorrect examples
Note: Public static fields should come first, followed by static fields and instance fields.
Note: Public static fields should come first, followed by static fields and instance fields.
Correct examples
Custom classes
configuration
classes
configurationNote: If this is not set, the default
will automatically be applied to classes as well. If a classes
configuration is provided, only this configuration will be used for classes
(i.e. nothing will be merged with default
).
Note: The configuration for classes
does not apply to class expressions (use classExpressions
for them).
Configuration: { "classes": ["method", "constructor", "field"] }
{ "classes": ["method", "constructor", "field"] }
Incorrect example
Correct example
Configuration: { "classes": ["public-instance-method", "public-static-field"] }
{ "classes": ["public-instance-method", "public-static-field"] }
Incorrect example
Correct example
Custom classExpressions
configuration
classExpressions
configurationNote: If this is not set, the default
will automatically be applied to classes expressions as well. If a classExpressions
configuration is provided, only this configuration will be used for classExpressions
(i.e. nothing will be merged with default
).
Note: The configuration for classExpressions
does not apply to classes (use classes
for them).
Configuration: { "classExpressions": ["method", "constructor", "field"] }
{ "classExpressions": ["method", "constructor", "field"] }
Incorrect example
Correct example
Configuration: { "classExpressions": ["public-instance-method", "public-static-field"] }
{ "classExpressions": ["public-instance-method", "public-static-field"] }
Incorrect example
Correct example
Custom interfaces
configuration
interfaces
configurationNote: If this is not set, the default
will automatically be applied to classes expressions as well. If a interfaces
configuration is provided, only this configuration will be used for interfaces
(i.e. nothing will be merged with default
).
Note: The configuration for interfaces
only allows a limited set of member types: signature
, field
, constructor
and method
.
Note: The configuration for interfaces
does not apply to type literals (use typeLiterals
for them).
Configuration: { "interfaces": ["signature", "method", "constructor", "field"] }
{ "interfaces": ["signature", "method", "constructor", "field"] }
Incorrect example
Correct example
Custom typeLiterals
configuration
typeLiterals
configurationNote: If this is not set, the default
will automatically be applied to classes expressions as well. If a typeLiterals
configuration is provided, only this configuration will be used for typeLiterals
(i.e. nothing will be merged with default
).
Note: The configuration for typeLiterals
only allows a limited set of member types: signature
, field
, constructor
and method
.
Note: The configuration for typeLiterals
does not apply to interfaces (use interfaces
for them).
Configuration: { "typeLiterals": ["signature", "method", "constructor", "field"] }
{ "typeLiterals": ["signature", "method", "constructor", "field"] }
Incorrect example
Correct example
Sorting alphabetically within member groups
It is possible to sort all members within a group alphabetically.
Configuration: { "default": { "memberTypes": <Default Order>, "order": "alphabetically" } }
{ "default": { "memberTypes": <Default Order>, "order": "alphabetically" } }
This will apply the default order (see above) and enforce an alphabetic order within each group.
Incorrect examples
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" } }
{ "default": { "memberTypes": "never", "order": "alphabetically" } }
Incorrect example
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.
Compatibility
TSLint: member-ordering
Last updated