Linters are static analysis tools that examine source code without executing it, identifying bugs, style violations, security vulnerabilities, and code quality issues before runtime. Originally coined in 1978 for C programming, linting has evolved into a critical practice across all modern languages, enforcing team coding standards, catching errors early in development, and improving maintainability. Unlike formatters that only adjust whitespace and layout, linters analyze code semantics — detecting unused variables, type mismatches, deprecated patterns, and anti-patterns that compilers often miss. In 2026, a wave of Rust-written tools (Ruff, Oxlint, ty, Biome) has dramatically raised the performance baseline, while AI-assisted platforms (SonarQube, Semgrep, DeepSource) bring deeper context-aware analysis. Understanding which linter fits your language, performance needs, and integration requirements is essential for maintaining high-quality codebases at scale.
What This Cheat Sheet Covers
This topic spans 11 focused tables and 59 indexed concepts. Below is a complete table-by-table outline of this topic, spanning foundational concepts through advanced details.
Table 1: JavaScript and TypeScript Linters
| Linter | Example | Description |
|---|---|---|
npx eslint . --fixeslint.config.js (flat config) | • Pluggable JavaScript linter with 650+ configurable rules • v10 requires flat config ( eslint.config.js) only — legacy .eslintrc fully removed• adds correct JSX reference tracking to eliminate false no-unused-vars positives. | |
npx oxlintoxlint src/ | • 50-100× faster than ESLint • written in Rust • v1.0 stable released • growing ESLint plugin compatibility • ideal for large codebases where linting speed is the bottleneck. | |
npx @biomejs/biome check .biome format --write | • All-in-one linter + formatter (replaces ESLint + Prettier) • supports JS, TS, JSX, JSON, CSS, HTML, GraphQL • 97% Prettier-compatible. |