Perfectionist

sort-interfaces

Enforce sorted TypeScript interface properties.

Sorting interface properties in TypeScript provides a clear and predictable structure to the codebase. This rule helps developers locate various properties defined within an interface more easily, promoting consistency and enabling efficient maintenance and collaboration.

Additionally, it ensures that property comments are sorted along with the properties themselves, preserving documentation clarity.

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.

It’s safe. If you document interface properties line by line, property comments will also be sorted.

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 interfaces that should be ignored by this rule. This can be useful if you have specific interfaces that you do not want to sort.

You can specify their names or a regexp pattern to ignore, for example: '^Component.+' to ignore all interfaces whose names begin with the word “Component”.

partitionByComment

default: false

Allows you to use comments to separate the properties of interfaces into logical groups. This can help in organizing and maintaining large interfaces by creating partitions within the interface 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[] — An array 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 interface if there is an empty line between them. This can be useful for keeping logically separated groups of members in their defined order.

interface User {
  // Group 1
  firstName: string;
  lastName: string;

  // Group 2
  age: number;
  birthDate: Date;

  // Group 3
  address: 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 interface groups.

  • ignore — Do not report errors related to new lines between interface groups.
  • always — Enforce one new line between each group, and forbid new lines inside a group.
  • never — No new lines are allowed between interface members.

This options is only applicable when partitionByNewLine is false.

[DEPRECATED] groupKind

default: 'mixed'

Use the groups option with the optional and required modifiers instead.

Specifies how optional and required members should be ordered in TypeScript interfaces.

  • 'optional-first' — Put all optional members before required members.
  • 'required-first' — Put all required members before optional members.
  • 'mixed' — Do not enforce any specific order based on optionality.

groups

type: Array<string | string[]>

default: []

Allows you to specify a list of interface member groups for sorting. Groups help organize members into categories, making your interfaces more readable and maintainable.

Each interface member 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

interface 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',
  ]
}

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:

  1. The group with the most modifiers matching will be selected.
  2. 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 or optional-multiline-method.
  • multiline-method.
  • optional-method.
  • method.
  • multiline-optional-member or optional-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>

default: {}

You can define your own groups and use regexp patterns to match specific interface 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 — An interface member’s name matching the value will be marked as part of the group referenced by the key.
  • string[] — An interface 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.

interface 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.1.0.

Resources

Table of Contents