โก Performance tips
Depending on the device you are operating on, in-editor performance can be a concern with Sheriff.
@typescript-eslint
can be particularly taxing on the system, so, some performance considerations are in order.
Rules performance benchmarkingโ
The currently known slowest rules in Sheriff are the ones of @typescript-eslint
that requires type information โ to work.
List of types-aware rules โ.
You can benchmark rules performance by yourself by running the following command in the terminal:
- npm
- Yarn
- pnpm
TIMING=1 npm run eslint
TIMING=1 yarn eslint
TIMING=1 pnpm run eslint
Learn more in the ESLint official docs section โ.
Rules performance optimization strategiesโ
There are a few techniques you can leverage to improve slow linting time.
You can choose which technique to employ or mix-and-match them.
Disable some of the heaviest rulesโ
As simple as it sounds, you could assess which of the slowest rules you can live without and simply disable them.
Enable some of the heaviest rules only on CIโ
This approach has a little more overhead, but you could try to run the heaviest rules only on CI.
Here is an example on how you can achieve it:
- JS
- TS
import sheriff from "eslint-config-sheriff";
import { defineFlatConfig } from "eslint-define-config";
const sheriffOptions = {
react: false,
next: false,
astro: false,
lodash: false,
playwright: false,
jest: false,
vitest: false,
};
export default defineFlatConfig([
...sheriff(sheriffOptions),
{
rules: {
"@typescript-eslint/no-misused-promises": process.env.CI ? 2 : 0,
},
},
]);
import sheriff from "eslint-config-sheriff";
import { defineFlatConfig } from "eslint-define-config";
import type { SheriffSettings } from "@sherifforg/types";
const sheriffOptions: SheriffSettings = {
react: false,
next: false,
astro: false,
lodash: false,
playwright: false,
jest: false,
vitest: false,
};
export default defineFlatConfig([
...sheriff(sheriffOptions),
{
rules: {
"@typescript-eslint/no-misused-promises": process.env.CI ? 2 : 0,
},
},
]);
This is a tradeoff, as this approach is a DX degradation and could lead to some developer frustration, because perfectly valid code in local environment could instead fail in CI.
Adopt ESLint cacheโ
ESLint features an internal cache where you can store your previous runs.
This technique has pretty much no downsides and you should employ it in any case, regardless of any other factor.
Read the official docs on ESLint caching here: command-line-interface#caching โ.
Instead, if your project lives in a monorepo, you can follow this guide โ.
Review glob patternsโ
ESLint, Typescript and Sheriff use minimatch syntax to handle glob patterns.
Wide glob patterns can lead to performance degradation.
Pay special attention to: