Code Style. TypeScript

Use tab character

• If this checkbox is selected, tab characters are used:

  • On pressing the Tab key

  • For indentation

  • For reformatting code

• If the checkbox is cleared, JetBrains Rider uses spaces instead of tabs.

Smart tabs

An indentation consists of two parts. One part results from nesting code blocks, and the other part is determined by alignment.

• If this checkbox is selected, the part that results from nesting contains both tabs and spaces (if necessary), while the part defined by alignment consists only of spaces.

• If this checkbox is cleared, only tabs are used. This means that after reformatting a group of spaces that fits the specified tab size is automatically replaced with a tab, which may result in breaking fine alignment.

tip

The Smart Tabs checkbox is available if the Use tab character checkbox is selected.

Tab size

In this field, specify the number of spaces that fits in a tab.

Indent

In this field, specify the number of spaces to be inserted for each indent level.

Continuation indent

In this field, specify the number of spaces to be inserted between the elements of an array, in expressions, method declarations, and method calls.

Keep indents on empty lines

If this checkbox is selected, JetBrains Rider retains indents on empty lines as if they contained some code. If the checkbox is cleared, JetBrains Rider deletes the tab characters and spaces on empty lines.

Indent chained methods

In declarations of functions, the second and further methods in a chain are displayed on a separate line.

• When the checkbox is selected, the second and further methods in a chain are aligned with the first call.

• When the checkbox is cleared, the second and further methods in a chain are aligned with the object on which they are invoked.

Indent all chained calls in a group

When this checkbox is selected, the first and the further called methods are indented.

The checkbox is available only when the Indent chained methods checkbox is selected.

Indent all chained calls is off

Indent all chained calls on

Hard wrap at

In this field, specify the number of spaces required to the right of an element. If you accept the Default option then the value from the global settings is used.

Wrap on typing

In this field, specify how the edited text is fitted in the specified Hard wrap at field.

• Default: choose this option to use the Wrap on typing value from the global settings.

• Yes: choose this option to use the value from the Right Margin field.

• No: if you choose this option a line can exceed the value specified in the right margin.

Visual guides

In this field, specify multiple right margins. You can leave a default value or enter the number of spaces for your margin. If you want to specify several margins, enter numbers separated by comma.

Keep when reformatting

Use the checkboxes to configure exceptions that JetBrains Rider will make when reformatting the source code. For example, by default, the Line breaks checkbox is selected.

If your code contains lines that are shorter than a standard convention, you can convert them by disabling the Line breaks checkbox before reformatting.

Wrapping options

A wrapping style applies to various code constructs, specified in the left-hand pane (for example, method call arguments, or assignment statements).

• Do not wrap - When this option is selected, no special wrapping style is applied, the nested alignment and braces settings are ignored.

• Wrap if long - Select this option to wrap lines that go beyond the right margin with proper indentation.

• Wrap always - Select this option to wrap all elements in lists so that there is one element per line with proper indentation.

• Chop down if long - Select this option to wrap elements in lists that go beyond the right margin so that there is one element per line with proper indentation.

Alignment options

• Align when multiline - If this checkbox is selected, a code construct starts at the same column on each next line. Otherwise, the position of a code construct is determined by the current indentation level.

• <character(s)> on next line - Select this checkbox to move the specified character or characters to the next line when the lines are wrapped.

• 'else' on new line - Use this checkbox to move the corresponding statements or characters to the next line.

• New line after <character> - Select this checkbox to move the code after the specified character to a new line.

• Special else if treatment - If this checkbox is selected, else if statements are located in the same line.

  Otherwise, else if statements are moved to the next line to the corresponding indent level.

• Indent case branches - If this checkbox is selected, the case statement is located at the corresponding indent level. Otherwise, case statement is placed at the same indent level with switch.

• Objects - From the list, choose how to align objects:

  • Do not align: the attributes in sequential lines will be not aligned.

  • On colon: the attributes in sequential lines will be aligned against the colon.

  • On value: the attributes in sequential lines will be aligned against the value.

• Variable declarations - Choose one of the following options to configure alignment for equality signs:

  • Do not align: the equality signs are not aligned.

  • Align when multiline: the equality signs in multiline var statements are aligned by inserting additional spaces.

  • Align when grouped: the equality signs in multiple var statements are aligned by inserting additional spaces.

• ES6 import/export When the Align 'from' clauses: checkbox is selected, JetBrains Rider aligns import and export statements in ECMAScript 6 code automatically making your code easier to read and maintain. Compare the appearance of a code fragment with alignment and without it in the Preview pane.

  

  With this option on, JetBrains Rider will align the new code on the fly. Existing import and export statements will be aligned after you reformat the code by pressing CtrlAltEnter.

Braces placement options

Keep Maximum Blank Lines

In this area, specify the number of extra blank lines to be kept after reformatting.

Minimum Blank Lines

In this area, configure whether to have or not to have extra empty lines after the blocks of import statements and around classes, fields, methods, or functions. In the field next to each option, specify the minimum number of extra blank lines to be left.

Semicolon to terminate statements

• Use semicolon to terminate statements in new code

• Use semicolon to terminate statements always

• Don't use semicolon to terminate statements in new code

• Don't use semicolon to terminate statements always

Quotes

• Use double quotes in new code

• Use double quotes always

• Use single quotes in new code

• Use single quotes always

Trailing comma

Use this list to configure whether you want to use trailing commas in objects, arrays, and for the parameters in method definitions and calls. The available options are:

• Keep

• Remove

• Add when multiline

Use 'public' modifier

Use this checkbox to have the public access modifier inserted or omitted in the generated code.

For example, during generation of a public method from the following:

class Test {
    public test():void {
        var x = 1;
    }
}

• If the checkbox is selected, the public access modifier is automatically inserted in the generated code:

  class Test {
      public test():void {
          this.extracted();
      }
      public extracted() {
          var x = 1;
      }
  }

• If the checkbox is cleared, the public access modifier is omitted during code generation:

  class Test {
      public test():void {
          this.extracted();
      }
      extracted() {
          var x = 1;
      }
  }

See TypeScript Language Handbook, chapter Private/Public Modifiers.

Naming conventions

In this area:

• Configure or accept default prefixes that will be added automatically to the names of generated fields and properties.

• Choose the style for the names of generated files. For example, when JetBrains Rider suggests moving a class to a new automatically generated file the suggested name of this file is generated from the class name in accordance with the chosen style. Learn more from Keeping the names of classes and containing files in compliance

Comment Code

In this area, configure code style for generated comments.

• Include types in JSDoc: select this checkbox to add types for @param, @return, and other tags automatically. Note that type information is extraneous for TypeScript as types are retrieved from the code itself. Accordingly, the checkbox is cleared by default.

• Line comment at first column: select this checkbox to start line comments at the first column. When the checkbox is cleared, line comments are aligned in the code.

• Add a space at line comment start: when this checkbox is selected, a space will be inserted between a line comment character and the first character of a commented line.

  Add a space at line comment start off

  Add a space at line comment start on

  

  

  tip

  The Add a space at line comment start checkbox is unavailable when Line comment at first column is selected.

• Add spaces around block comments: select this checkbox to add leading and trailing spaces in block comments.

  By default, when you enclose a code fragment in a block comment, the text starts right after the opening /* characters without any spaces. Before the closing */ characters no space is inserted either. This default code style may conflict with some linters' rules, for example, ESLint.

  Add a space at block comment start off

  Add a space at block comment start on

  

  

Merge imports for members from the same module

• When this checkbox is selected, imported symbols from the same module are listed in one import statement with a comma as separator. The members are listed in the order in which they are imported. To arrange them alphabetically, select the Sort imported members checkbox and run Code | Optimize Imports.

• When this checkbox is cleared, for each imported symbol a separate import statement is generated.

Use paths relative to tsconfig.json

When this checkbox is selected, JetBrains Rider calculates import paths using the tsconfig.json file as the root. When this checkbox is cleared, JetBrains Rider calculates import paths relative to the project root.

For example, if your project is structured as follows:

With the checkbox selected, JetBrains Rider generates the following import statement:

import {ClassName} from 'directory_2/file_2'

If the checkbox is cleared, the following import statement is generated:

import {ClassName} from '../directory_2/file_2'

Use directory import when index.js is available (Node-style module resolution)

Suppose, you have a project with the following structure:

• When this checkbox is cleared, For example, the file src/lib/index.js will be imported as ./src/lib/index.js.

• If the checkbox is selected, the file src/lib/index.js will be imported as ./src/lib.

Learn more about TypeScript module resolution from the TypeScript official website.

Use file extension

In this field, configure file extensions in import statements.

• Auto - with this option, JetBrains Rider always adds extensions to the names of the following files:

  • .vue files.

  • Files with the .mts extension.

  • Files from projects with "type":"module" in package.json and with "module":"node16" or "module":"nodenext" in tsconfig.json.

• Always .js - with this option, JetBrains Rider automatically adds extensions to the names of files in import statements. That is important when you use ES6 modules in a browser that requires full file names (for example, in Chrome). JetBrains Rider applies this setting both when it generates an import statement automatically, on code completion, or when you invoke import generation with AltEnter.

• Never - with this option, JetBrains Rider always inserts file names without extensions when generating import statements.

Use type modifier in imports

In this field, configure the use of the type modifier in import statements for types. Note that the settings apply only for types, no type modifier is inserted for not types, no matter which option you select.

Auto

Always with type

Never

With this option, a type modifier is added if "importsNotUsedAsValues": "error" or "verbatimModuleSyntax": true is specified in your tsconfig.json.

Otherwise, if no import type is preferred, no type modifier is inserted.

Gif

With this option, a type modifier is always inserted, no matter whether "importsNotUsedAsValues": "error" or "verbatimModuleSyntax": true is specified in your tsconfig .json:

Gif

With this option, JetBrains Rider never uses the type modifier, regardless of the "importsNotUsedAsValues": "error" or "verbatimModuleSyntax": true flags in your tsconfig.json:

Gif

Use path mappings from tsconfig.json

In this field, configure the style for paths in import statements.

• Always - with this option, JetBrains Rider always uses path mappings from your tsconfig.json.

• Never - with this option, JetBrains Rider always uses relative paths in generated imports.

• Only in files outside specified paths - with this option, JetBrains Rider uses relative paths when generating imports between the files for which the same path mapping is defined. In all other files the path mapping will be used.

In the example below, the files animal.ts and bird.ts are stored in the folders under the animated folder for which a path mapping is specified in tsconfig.json. The file dog.ts is outside the path mapping.

The path mapping @Lib is configured as follows:

"baseUrl": ".",
"paths": {
  "@lib/*": ["./lib/objects/earth/animated/*"]
}

As a result, each of the Always and Never options is applied to both bird.ts and dog.ts in the same way. With the Only in files outside specified paths option selected, JetBrains Rider generates import statements of different styles: with a relative path in bird.ts and with a path mapping in dog.ts.

Always

Never

Only in files outside specified paths

Import statements use the @Lib path mapping.

Import statements use relative paths.

JetBrains Rider generates import statements of different styles: with a relative path in bird.ts and with the @Lib path mapping in dog.ts.

Do not import exactly from

In this field, specify the exact paths that JetBrains Rider should skip during automatic import of a symbol. Instead, JetBrains Rider will look for alternative paths to import the symbol.

This is particularly useful for modules that allow importing their submodules instead of the entire module. For example, to prefer imports like import {Observable} from 'rxjs/Observable' to a more general import {Observable} from 'rxjs', add rxjs to the list.

To manage the list of modules to skip:

1. Click to the right of the field.

2. In the Change modules dialog that opens, click and specify the module name in the Add module dialog. To remove a module from the list, select it and click .

Sort imported members

• When this checkbox is selected, JetBrains Rider lists the imported members in merged import statements alphabetically. Note that the members are listed comma-separated in the order they are imported and re-sorted only when you run Code | Optimize Imports.

• When this checkbox is cleared, the members in merged import statements are always listed comma-separated in the order they are imported.

Sort imports by modules

• When this checkbox is selected, import statements are re-sorted alphabetically by the module names when you run Code | Optimize Imports.

• When this checkbox is cleared, import statements are always shown in the order they are generated and this order is not changed after you run Code | Optimize Imports.

Grouping Rules

Use this area to set the grouping rules.

• Group property field with corresponding getter/setter

• Group fields initialized with arrow functions with methods

• Keep overridden methods together

  Select this checkbox to group the overridden methods together by class and interface. In order list, select keep order or order by name options.

Matching rules

Use this area to define elements order as a list of rules, where every rule has a set of matches such as modifier or type.

• : use this button to add a rule. The empty rule area opens.

• : use this button to remove the rule from the list.

• : use this button to edit an existing rule. To see this button, navigate to the rule that you want to edit and click the button. In popup that opens, modify the rule fields.

• : use these buttons to move the selected rule up or down.

Empty rule

Use this area to create a new matching rule or edit an existing one. You can select from the following filters:

• Type: use this filter to choose classes or methods for your rule.

  Note that clicking a type keyword twice negates the condition.

• Modifier: use this filter to select the types of modifiers for the rule.

  Note that clicking a modifier keyword twice negates the condition.

• Name: use this field to specify entry names in the rule. This filter matches only entry names, such as field names, method names, class names, and so on. The filter supports regular expressions and uses a standard syntax. The match is performed against the entire name.

• Order: use this list to select the sorting order for the rule. This option is useful when more than one element uses the same matching rule. In this case, selecting Keep order will keep the same order as was set before the rearrangement and selecting Order by Name will sort the elements with the same matching rule by their names.

• Aliases: this option displays aliases that were defined in the Rules Alias Definition dialog. You can remove the ones you do not need.

This icon appears when you select Order by Name from the Order list. The icon indicates that the items in this rule are sorted alphabetically.