Skip to main content

Performance

As mentioned in Linting with Type Information, if you're using type-aware linting, your lint times should be roughly the same as your build times. Most performance slowdowns in ESLint rules are from type-aware lint rules calling to TypeScript's type checking APIs.

If you're experiencing lint times much slower than type-checking times, then there are a few common culprits.

Slow ESLint Rules​

ESLint includes a TIMING=1 option documented in Profile Rule Performance that give a high-level overview of rule speeds. However, because TypeScript utilizes internal caching, a project's first type-aware lint rule will almost always seem the slowest.

When investigating which lint rules are the slowest in your project, be sure to run them one at a time and compare those timing measurements separately.

To enable more complete verbose logging, you can use any of:

  • eslint --debug: to enable all of ESLint's debug logs on the CLI
  • parserOptions.debugLevel: a shortcut to set eslint, typescript, and/or typescript-eslint
  • Directly setting the DEBUG environment variable for debug: e.g. DEBUG=typescript-eslint:* eslint

Slow TypeScript Types​

Running typed linting on a project is generally as slow as type checking that same project. If TypeScript's type checker runs slowly on your project, then typed linting will as well.

The TypeScript Wiki's Performance page includes general performance tips and steps to investigate slow type checking. In particular for typed linting:

Wide includes in your tsconfig​

When using type-aware linting, you provide us with one or more tsconfigs. We then will pre-parse all files so that full and complete type information is available.

If you provide very wide globs in your include (such as **/*), it can cause many more files than you expect to be included in this pre-parse. Additionally, if you provide no include in your tsconfig, then it is the same as providing the widest glob.

Wide globs can cause TypeScript to parse things like build artifacts, which can heavily impact performance. Always ensure you provide globs targeted at the folders you are specifically wanting to lint.

Project Service Issues​

Changes to extraFileExtensions with projectService​

Using a different extraFileExtensions between files in the same project with the projectService option may cause performance degradations. For every file linted, we update the projectService whenever extraFileExtensions changes. This causes the underlying TypeScript server to perform a full project reload.

eslint.config.js
// @ts-check

import tseslint from 'typescript-eslint';
import vueParser from 'vue-eslint-parser';

const extraFileExtensions = ['.vue'];
export default [
  {
    files: ['*.ts'],
    languageOptions: {
      parser: tseslint.parser,
      parserOptions: {
        projectService: true,
        extraFileExtensions,
      },
    },
  },
  {
    files: ['*.vue'],
    languageOptions: {
      parser: vueParser,
      parserOptions: {
        projectService: true,
        parser: tseslint.parser,
        extraFileExtensions: ['.vue'],
        extraFileExtensions,
      },
    },
  },
];

Project reloads can be observed using the debug environment variable: DEBUG='typescript-eslint:typescript-estree:*'.

typescript-estree:useProgramFromProjectService Updating extra file extensions: before=[]: after=[ '.vue' ]
typescript-estree:tsserver:info reload projects.
typescript-estree:useProgramFromProjectService Extra file extensions updated: [ '.vue' ]
...
typescript-estree:useProgramFromProjectService Updating extra file extensions: before=[ '.vue' ]: after=[]
typescript-estree:tsserver:info reload projects.
typescript-estree:useProgramFromProjectService Extra file extensions updated: []
...
typescript-estree:tsserver:info Scheduled: /path/to/tsconfig.src.json, Cancelled earlier one +0ms
typescript-estree:tsserver:info Scheduled: *ensureProjectForOpenFiles*, Cancelled earlier one +0ms
...
typescript-estree:useProgramFromProjectService Updating extra file extensions: before=[]: after=[ '.vue' ]
typescript-estree:tsserver:info reload projects.
typescript-estree:useProgramFromProjectService Extra file extensions updated: [ '.vue' ]

Traditional Project issues​

Wide includes in your ESLint options​

tip

The new "project service" in v8 requires no additional configuration for wide TSConfig includes. If you're using parserOptions.projectService, this problem is solved for you.

Specifying tsconfig.json paths in an ESLint parserOptions.project configuration is also likely to cause much more disk IO than expected. Instead of globs that use ** to recursively check all folders, prefer paths that use a single * at a time.

eslint.config.mjs
// @ts-check

import eslint from '@eslint/js';
import tseslint from 'typescript-eslint';

export default tseslint.config(
  eslint.configs.recommended,
  tseslint.configs.recommendedRequiringTypeChecking,
  {
    languageOptions: {
      parserOptions: {
        tsconfigRootDir: import.meta.dirname,
        project: ['./**/tsconfig.json'],
        project: ['./packages/*/tsconfig.json'],
      },
    },
  },
);

See Glob pattern in parser's option "project" slows down linting for more details.

Third-Party Plugins​

@stylistic/ts/indent and other stylistic rules rules​

The @stylisic/ts/indent rule helps ensure your codebase follows a consistent indentation pattern. However this involves a lot of computations across every single token in a file. Across a large codebase, these can add up, and severely impact performance.

We recommend not using this rule, and instead using a tool like prettier to enforce a standardized formatting.

See our documentation on formatting for more information.

eslint-plugin-prettier​

This plugin surfaces Prettier formatting problems at lint time, helping to ensure your code is always formatted. However this comes at a quite a large cost - in order to figure out if there is a difference, it has to do a Prettier format on every file being linted. This means that each file will be parsed twice - once by ESLint, and once by Prettier. This can add up for large codebases.

Instead of using this plugin, we recommend using Prettier's --check flag to detect if a file has not been correctly formatted. For example, our CI is setup to run the following command automatically, which blocks PRs that have not been formatted:

npm run prettier --check .

See Prettier's --check docs for more details.

eslint-plugin-import​

This is another great plugin that we use ourselves in this project. However there are a few rules which can cause your lints to be really slow, because they cause the plugin to do its own parsing, and file tracking. This double parsing adds up for large codebases.

There are many rules that do single file static analysis, but we provide the following recommendations.

We recommend you do not use the following rules, as TypeScript provides the same checks as part of standard type checking:

  • import/named
  • import/namespace
  • import/default
  • import/no-named-as-default-member
  • import/no-unresolved (as long as you are using import over require)

The following rules do not have equivalent checks in TypeScript, so we recommend that you only run them at CI/push time, to lessen the local performance burden.

  • import/no-named-as-default
  • import/no-cycle
  • import/no-unused-modules
  • import/no-deprecated

import/extensions enforcing extensions are used​

If you want to enforce file extensions are always used and you're NOT using moduleResolution node16 or nodenext, then there's not really a good alternative for you, and you should continue using the import/extensions lint rule.

If you want to enforce file extensions are always used and you ARE using moduleResolution node16 or nodenext, then you don't need to use the lint rule at all because TypeScript will automatically enforce that you include extensions!

import/extensions enforcing extensions are not used​

On the surface import/extensions seems like it should be fast for this use case, however the rule isn't just a pure AST-check - it has to resolve modules on disk so that it doesn't false positive on cases where you are importing modules with an extension as part of their name (eg foo.js resolves to node_modules/foo.js/index.js, so the .js is required). This disk lookup is costly and thus makes the rule slow.

If your project doesn't use any npm packages with a file extension in their name, nor do you name your files with two extensions (like bar.js.ts), then this extra cost probably isn't worth it, and you can use a much simpler check using the no-restricted-syntax lint rule.

The below config is several orders of magnitude faster than import/extensions as it does not do disk lookups, however it will false-positive on cases like the aforementioned foo.js module.

function banImportExtension(extension) {
  const message = `Unexpected use of file extension (.${extension}) in import`;
  const literalAttributeMatcher = `Literal[value=/\\.${extension}$/]`;
  return [
    {
      // import foo from 'bar.js';
      selector: `ImportDeclaration > ${literalAttributeMatcher}.source`,
      message,
    },
    {
      // const foo = import('bar.js');
      selector: `ImportExpression > ${literalAttributeMatcher}.source`,
      message,
    },
    {
      // type Foo = typeof import('bar.js');
      selector: `TSImportType > TSLiteralType > ${literalAttributeMatcher}`,
      message,
    },
    {
      // const foo = require('foo.js');
      selector: `CallExpression[callee.name = "require"] > ${literalAttributeMatcher}.arguments`,
      message,
    },
  ];
}

module.exports = {
  // ... other config ...
  rules: {
    'no-restricted-syntax': [
      'error',
      ...banImportExtension('js'),
      ...banImportExtension('jsx'),
      ...banImportExtension('ts'),
      ...banImportExtension('tsx'),
    ],
  },
};