sort-object-types
Enforce sorted object types.
This rule standardizes the order of members within an object type in TypeScript. By ensuring that the members are sorted, it enhances readability without affecting the type system or code behavior.
This practice promotes a clear and consistent structure, making it easier for developers to understand and maintain object types.
Important
If you use the adjacent-overload-signatures
rule from the @typescript-eslint/eslint-plugin
plugin, it is highly recommended to disable it to avoid conflicts.
Try it out
Options
This rule accepts an options object with the following properties:
type
default:'alphabetical'
Specifies the sorting method.
'alphabetical'
— Sort items alphabetically (e.g., “a” < “b” < “c”) using localeCompare.'natural'
— Sort items in a natural order (e.g., “item2” < “item10”).'line-length'
— Sort items by the length of the code line (shorter lines first).
order
default:'asc'
Determines whether the sorted items should be in ascending or descending order.
'asc'
— Sort items in ascending order (A to Z, 1 to 9).'desc'
— Sort items in descending order (Z to A, 9 to 1).
ignoreCase
default:true
Controls whether sorting should be case-sensitive or not.
true
— Ignore case when sorting alphabetically or naturally (e.g., “A” and “a” are the same).false
— Consider case when sorting (e.g., “a” comes before “A”).
specialCharacters
default:keep
Controls whether special characters should be trimmed, removed or kept before sorting.
'keep'
— Keep special characters when sorting (e.g., “_a” comes before “a”).'trim'
— Trim special characters when sorting alphabetically or naturally (e.g., “_a” and “a” are the same).'remove'
— Remove special characters when sorting (e.g., “/a/b” and “ab” are the same).
locales
default:'en-US'
Specifies the sorting locales. See String.prototype.localeCompare() - locales.
string
— A BCP 47 language tag (e.g.'en'
,'en-US'
,'zh-CN'
).string[]
— An array of BCP 47 language tags.
ignorePattern
default:[]
Allows you to specify names or patterns for object types that should be ignored by this rule. This can be useful if you have specific object types that you do not want to sort.
You can specify their names or a regexp pattern to ignore, for example: '^Component.+'
to ignore all object types whose names begin with the word “Component”.
partitionByComment
default:false
Allows you to use comments to separate the members of types into logical groups. This can help in organizing and maintaining large object types by creating partitions based on comments.
true
— All comments will be treated as delimiters, creating partitions.false
— Comments will not be used as delimiters.string
— A regexp pattern to specify which comments should act as delimiters.string[]
— A list of regexp patterns to specify which comments should act as delimiters.
partitionByNewLine
default:false
When true
, the rule will not sort the members of an object if there is an empty line between them. This can be useful for keeping logically separated groups of members in their defined order.
type User = {
// Group 1
firstName: string;
lastName: string;
// Group 2
age: number;
birthDate: Date;
// Group 3
address: {
street: string;
city: string;
};
phone?: string;
};
Each group of members (separated by empty lines) is treated independently, and the order within each group is preserved.
newlinesBetween
default:'ignore'
Specifies how new lines should be handled between object type groups.
ignore
— Do not report errors related to new lines between object type groups.always
— Enforce one new line between each group, and forbid new lines inside a group.never
— No new lines are allowed in object types.
This options is only applicable when partitionByNewLine
is false
.
[DEPRECATED] groupKind
default:'mixed'
Use the groups option with the optional
and required
modifiers instead.
Allows you to group type object keys by their kind, determining whether required values should come before or after optional values.
mixed
— Do not group object keys by their kind; required values are sorted together optional values.required-first
— Group all required values before optional.optional-first
— Group all optional values before required.
groups
type: Array<string | string[]>
[]
Allows you to specify a list of type properties groups for sorting. Groups help organize properties into categories, making your type definitions more readable and maintainable.
Each property will be assigned a single group specified in the groups
option (or the unknown
group if no match is found). The order of items in the groups
option determines how groups are ordered.
Within a given group, members will be sorted according to the type
, order
, ignoreCase
, etc. options.
Individual groups can be combined together by placing them in an array. The order of groups in that array does not matter. All members of the groups in the array will be sorted together as if they were part of a single group.
Predefined groups are characterized by a single selector and potentially multiple modifiers. You may enter modifiers in any order, but the selector must always come at the end.
Example
type User = {
firstName: string // unknown
lastName: string // unknown
username: string // unknown
job: { // multiline
// Stuff about job
}
localization: { // multiline
// Stuff about localization
}
}
groups
option configuration:
{
groups: [
'unknown',
'method',
'multiline-member',
]
}
Index-signatures
- Selectors:
index-signature
,member
. - Modifiers:
required
,optional
,multiline
. - Example:
optional-index-signature
,index-signature
,member
.
Methods
- Selectors:
method
,member
. - Modifiers:
required
,optional
,multiline
. - Example:
optional-multiline-method
,method
,member
.
Properties
- Selectors:
property
,member
. - Modifiers:
required
,optional
,multiline
. - Example:
optional-property
,property
,member
.
Scope of the required
modifier
Elements that are not optional
will be matched with the required
modifier, even if the keyword is not present.
The unknown
group
Members that don’t fit into any group specified in the groups
option will be placed in the unknown
group. If the unknown
group is not specified in the groups
option, it will automatically be added to the end of the list.
Behavior when multiple groups match an element
The lists of modifiers above are sorted by importance, from most to least important. In case of multiple groups matching an element, the following rules will be applied:
- The group with the most modifiers matching will be selected.
- If modifiers quantity is the same, order will be chosen based on modifier importance as listed above.
Example :
interface Test {
optionalMethod?: () => {
property: string;
}
}
optionalMethod
can be matched by the following groups, from most to least important:
multiline-optional-method
oroptional-multiline-method
.multiline-method
.optional-method
.method
.multiline-optional-member
oroptional-multiline-member
.multiline-member
.optional-member
.member
.unknown
.
Example 2 (The most important group is written in the comments):
interface Interface {
// 'index-signature'
[key: string]: any;
// 'optional-property'
description?: string;
// 'required-method'
method(): string
customGroups
Migrating from the old API
Support for the object-based customGroups
option is deprecated.
Migrating from the old to the current API is easy:
Old API:
{
"key1": "value1",
"key2": "value2"
}
Current API:
[
{
"groupName": "key1",
"elementNamePattern": "value1"
},
{
"groupName": "key2",
"elementNamePattern": "value2"
}
]
type: Array<CustomGroupDefinition | CustomGroupAnyOfDefinition>
{}
You can define your own groups and use regexp pattern to match specific object type members.
Each key of customGroups
represents a group name which you can then use in the groups
option. The value for each key can either be of type:
string
— A type member’s name matching the value will be marked as part of the group referenced by the key.string[]
— A type member’s name matching any of the values of the array will be marked as part of the group referenced by the key. The order of values in the array does not matter.
Custom group matching takes precedence over predefined group matching.
Example
Put all properties starting with id
and name
at the top, combine and sort metadata and optional multiline properties at the bottom. Anything else is put in the middle.
type User = {
id: string // top
name: string // top
age: number // unknown
isAdmin: boolean // unknown
lastUpdated_metadata: Date // bottom
localization?: { // multiline
// Stuff about localization
}
version_metadata: string // bottom
}
groups
and customGroups
configuration:
{
groups: [
+ 'top',
'unknown',
+ ['optional-multiline', 'bottom']
],
+ customGroups: [
+ {
+ groupName: 'top',
+ selector: 'property',
+ elementNamePattern: '^(?:id|name)$',
+ },
+ {
+ groupName: 'bottom',
+ selector: 'property',
+ elementNamePattern: '.+_metadata$',
+ }
+ ]
}
Usage
Version
This rule was introduced in v0.11.0.