Perfectionist

sort-modules

Enforce sorted module members.

Organizing module members in a consistent order improves both readability and maintainability.

This rule helps developers quickly locate module members and understand the overall structure of your file.

By sorting module members systematically, confusion is minimized, and the code becomes more intuitive to navigate. This practice not only aids in individual productivity but also enhances team collaboration by establishing clear and predictable coding standards.

Try it out

What this rule sorts

This rule sorts the following module members:

  • enum
  • interface
  • type
  • class
  • function

The following elements are not sorted by this rule:

  • imports (see the sort-imports rule).
  • 'from' exports (see the sort-exports rule).
  • any other expression, in order to ensure compilation and runtime behavior.

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.

partitionByComment

default: false

Allows you to use comments to separate the module members into logical groups. This can help in organizing and maintaining large modules by creating partitions within the enum 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.

partitionByNewLine

default: false

When true, the rule will not sort the members of a class if there is an empty line between them. This can be useful for keeping logically separated groups of members in their defined order.

// Group 1
interface BasicInformation {
  firstName: string;
  lastName: string;
 }

// Group 2
interface AgeInformation {
  age: number;
  birthDate: Date;
}

// Group 3
interface LocationInformation {
  street: string;
  city: string;
}

// Group 4
function updateAddress(address: string) {}
function updatePhone(phone?: string) {}

// Group 5
function editFirstName(firstName: string) {}
function editLastName(lastName: string) {}

newlinesBetween

default: 'ignore'

Specifies how new lines should be handled between module member 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.

groups

type: Array<string | string[]>

default:

[
  'declare-enum',
  'export-enum',
  'enum',
  ['declare-interface', 'declare-type'],
  ['export-interface', 'export-type'],
  ['interface', 'type'],
  'declare-class',
  'class',
  'export-class',
  'declare-function',
  'export-function',
  'function',
]

Allows you to specify a list of module member groups for sorting. Groups help organize module members into categories, prioritizing them during sorting.

Each module 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.

Interfaces

  • Selector: interface.
  • Modifiers: declare, default, export.
  • Example: declare-interface, export-default-interface or interface.

Types

  • Selector: type.
  • Modifiers: declare, export.
  • Example: declare-type, declare-export-type or interface.

Classes

  • Selector: class.
  • Modifiers: declare, default, decorated, export.
  • Example: declare-class, export-default-decorated-class or class.

Functions

  • Selector: function.
  • Modifiers: declare, default, async, export.
  • Example: async-function, export-default-function or function.

Enums

  • Selectors: enum.
  • Modifiers: declare, export.
  • Example: export-declare-enum or enum.
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, the members will remain in their original order.

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 :

export default class {}

field can be matched by the following groups, from most to least important:

  • default-export-class or export-default-class.
  • default-class.
  • export-class.
  • class.
  • unknown.

customGroups

type: Array<CustomGroupDefinition | CustomGroupAnyOfDefinition>

default: []

You can define your own groups and use regex for matching very specific module members.

A custom group definition may follow one of the two following interfaces:

interface CustomGroupDefinition {
  groupName: string
  type?: 'alphabetical' | 'natural' | 'line-length' | 'unsorted'
  order?: 'asc' | 'desc'
  selector?: string
  modifiers?: string[]
  elementNamePattern?: string
  decoratorNamePattern?: string
}

A module member will match a CustomGroupDefinition group if it matches all the filters of the custom group’s definition.

or:

interface CustomGroupAnyOfDefinition {
  groupName: string
  type?: 'alphabetical' | 'natural' | 'line-length' | 'unsorted'
  order?: 'asc' | 'desc'
  anyOf: Array<{
      selector?: string
      modifiers?: string[]
      elementNamePattern?: string
      decoratorNamePattern?: string
  }>
}

A module member will match a CustomGroupAnyOfDefinition group if it matches all the filters of at least one of the anyOf items.

Attributes

  • groupName: The group’s name, which needs to be put in the groups option.
  • selector: Filter on the selector of the element.
  • modifiers: Filter on the modifiers of the element. (All the modifiers of the element must be present in that list)
  • elementNamePattern: If entered, will check that the name of the element matches the pattern entered.
  • decoratorNamePattern: If entered, will check that at least one decorator matches the pattern entered.
  • type: Overrides the sort type for that custom group. unsorted will not sort the group.
  • order: Overrides the sort order for that custom group

Match importance

The customGroups list is ordered: The first custom group definition that matches an element will be used.

Custom groups have a higher priority than any predefined group.

Example:

 {
   groups: [
    ['export-interface', 'export-type'],
    'enum',
    'class',
+   'input-types-and-interfaces',
+   'output-types-and-interfaces',
+   'unsorted-functions',
    'unknown',
   ],
+  customGroups: [                               
+    [                                           
+      {                                         
+         groupName: 'input-types-and-interfaces',
+         anyOf: [                               
+           {                                    
+              selector: 'type',
+              elementNamePattern: 'Input'.      
+           },
+           {                                    
+              selector: 'interface',
+              elementNamePattern: 'Input'.      
+           },
+         ]                                      
+      },
+      {                                         
+         groupName: 'output-types-and-interfaces',
+         anyOf: [                               
+           {                                    
+              selector: 'type',
+              elementNamePattern: 'Output'
+           },
+           {                                    
+              selector: 'interface',
+              elementNamePattern: 'Output'
+           },
+         ]                                      
+      },
+      {                                         
+         groupName: 'unsorted-functions',
+         type: 'unsorted',
+         selector: 'function',
+      },
+    ]                                           
+  ]                                             
 }

Usage

Version

This rule was introduced in v4.0.0.

Resources

Table of Contents