ESLint

Visit Website

Introduction

ESLint finds and fixes problems in JavaScript code. It parses source into an abstract syntax tree and runs rules against it, reporting issues ranging from likely bugs, such as using a variable before it is defined or comparing to a constant expression, to stylistic conventions a team has agreed on.

The README emphasises that ESLint is completely pluggable: every rule is a plugin, and you can add more at runtime. That design produced an enormous ecosystem. typescript-eslint adds TypeScript parsing and type-aware rules; framework plugins cover React, Vue, Svelte and Angular; others target accessibility (jsx-a11y), imports, security patterns, testing libraries and more.

Configuration uses the flat config format in eslint.config.js, which became the default in ESLint 9. Each rule is set to off, warn or error, and shareable configs let organisations publish a baseline. Many rules support --fix, and suggestions in editors offer fixes that need a human decision.

ESLint is maintained by an independent team under the OpenJS Foundation. The project documents a support policy in its README: the current major version is supported, with six months of limited support for the previous major covering critical bugs, security and compatibility fixes.

Most teams run ESLint in three places: the editor for instant feedback, a pre-commit hook for changed files, and CI as a required check. In the quality loop it is the first gate for JavaScript and TypeScript code. Formatting is increasingly left to Prettier or Biome, while ESLint focuses on correctness and conventions.

The source code is at eslint/eslint on GitHub under the MIT licence, with about 27,600 stars; the most recent commit was on 11 November 2026.

For existing codebases, the smoothest migration to flat config is to run the official config migrator, then compare results before and after on the same commit. Keep the rule set small at first, use --max-warnings to stop new warnings from accumulating, and add type-aware rules from typescript-eslint once performance is acceptable. Caching with --cache and limiting CI runs to changed files keep feedback fast in large repositories.

Editor integration completes the loop: when developers see the same rules in their editor that CI enforces, most problems are fixed before a commit is made, and CI failures become rare. Sharing one config package across repositories keeps rules consistent between teams.

Features

1. Pluggable rules: Every rule is a plugin; add custom rules at runtime.
2. Flat config: eslint.config.js with explicit, composable configuration.
3. Auto-fix: --fix repairs many problems automatically.
4. TypeScript support: Via typescript-eslint, including type-aware rules.
5. Framework plugins: React, Vue, Svelte, Angular and more.
6. Shareable configs: Publish and reuse team baselines.
7. Caching: --cache speeds up repeated runs.
8. Formatters: Stylish, JSON, SARIF (via plugin) and others for CI.
9. Editor integrations: Official and community plugins for major editors.
10. Custom parsers: Lint languages and syntaxes beyond plain JavaScript.

Pros

1. Ecosystem: More plugins and shared configs than any other JavaScript linter.
2. Highly configurable: Rules can match almost any team convention.
3. Free to use: Open source under the MIT licence, so the core tool costs nothing to use.
4. Actively maintained: The repository had commits as recent as 11 November 2026.
5. Community: About 27,600 GitHub stars.

Cons

1. Performance on large repos: Type-aware rules can be slow on big TypeScript projects.
2. Config migration: Moving from legacy .eslintrc to flat config takes effort.
3. Plugin compatibility: Plugins must keep up with major ESLint releases.
4. Not a formatter: Teams usually add Prettier or another formatter.

Usage and Links (Example)

Initialise a config:

npm init @eslint/config@latest

A flat config with TypeScript:

// eslint.config.js
import js from "@eslint/js";
import tseslint from "typescript-eslint";

export default [
  js.configs.recommended,
  ...tseslint.configs.recommended,
  { rules: { "no-console": "warn", "prefer-const": "error" } },
];

Run in CI:

npx eslint . --max-warnings 0 --cache

Practical tips:

1. Use --max-warnings 0 in CI so warnings do not pile up.
2. Enable type-aware rules only where they add value, to keep runs fast.
3. Pair with reviewdog to report only on changed lines in legacy code.

Resources:

• ESLint website
• GitHub repository

Pricing

ESLint is free and open source under the MIT licence.

Recommended for?

1. Every JavaScript and TypeScript project.
2. Organisations publishing shared lint baselines.
3. Teams needing custom rules for internal APIs.
4. Consider Biome if speed and an all-in-one formatter matter more than plugins.

Conclusion

ESLint is the reference linter for JavaScript and TypeScript. Its plugin model, auto-fix and editor support make it a dependable first quality gate.

Plan the move to flat config, keep type-aware rules targeted, and enforce zero warnings in CI to get the most from it.

On CheckOps, ESLint is filed under the Release & CI gates stage. Related tools listed here include Biome, SonarQube, Semgrep, MegaLinter, pre-commit and reviewdog. Before standardising on one, compare recent maintenance activity, the pricing model as your usage grows, and the integrations you rely on today. Information on this page was verified against the official website, documentation and repository on 11 November 2026.