Code Formatting: A Technical Guide for Decision Makers#

Research Code: 1.104.2 Domain: Code Formatting & Linting Tools Audience: Engineering Managers, Tech Leads, CTOs Date: December 4, 2025

What This Document Covers#

This explainer provides foundational knowledge about code formatting concepts and terminology. It does NOT compare specific tools—see the 01-discovery/ research for tool comparisons.

Why Code Formatting Matters#

The Problem It Solves#

Without automated formatting:

• Developers waste time on style debates (“tabs vs spaces”)
• Code reviews focus on formatting instead of logic
• Merge conflicts arise from inconsistent whitespace
• Onboarding slows as new devs learn local conventions

The Business Case#

Developer Time Savings:

• Eliminates formatting discussions in code review
• Reduces cognitive load (one less decision per line)
• Faster onboarding (style is automatic)

Code Quality:

• Consistent style across entire codebase
• Easier to read = easier to maintain
• Better diffs = clearer code review

Quantified Impact:

• 15-30 minutes/week saved per developer on formatting debates
• 50%+ reduction in style-related code review comments
• ROI: 2-5 hours/week for a 10-person team

Glossary of Terms#

Core Concepts#

Formatter A tool that automatically reformats code to match a style guide. Input: messy code. Output: consistently styled code. The transformation is deterministic—same input always produces same output.

Linter A tool that analyzes code for potential errors, bugs, and style violations. Unlike formatters, linters don’t change code—they report problems. Examples: unused variables, potential bugs, complexity warnings.

Auto-fix When a linter can automatically fix certain issues. Not all linter warnings are auto-fixable. Example: “unused import” can be auto-fixed by removing it.

Style Concepts#

Opinionated Formatter A formatter with few/no configuration options. “One true style.” Example: Black (“any color you like, as long as it’s black”). Benefit: zero bikeshedding. Cost: no customization.

Configurable Formatter A formatter with many style options. Example: YAPF, Prettier (partially). Benefit: team can choose style. Cost: debates about configuration.

PEP 8 Python’s official style guide. Defines conventions like 4-space indentation, 79-character line length. Most Python formatters aim for PEP 8 compliance.

Technical Concepts#

AST (Abstract Syntax Tree) A tree representation of code structure. Formatters parse code to AST, then regenerate formatted code. AST captures meaning, not whitespace.

CST (Concrete Syntax Tree) Like AST but preserves all syntax details including whitespace and comments. More accurate but more complex. Used by advanced formatters.

Idempotent Running the formatter twice produces the same result as running once. Essential property—otherwise formatting would never converge.

Deterministic Same input always produces same output. Essential for reproducibility and CI/CD.

Integration Concepts#

Pre-commit Hook A script that runs before git commit. Can block commits if formatting fails. Ensures only formatted code enters the repository.

CI Check A CI/CD step that verifies formatting. Fails the build if code isn’t formatted. Common pattern: format --check (verify without modifying).

IDE Integration Format-on-save in editors like VS Code, PyCharm. Formats code automatically when file is saved. Best developer experience.

pyproject.toml / package.json Configuration files for Python/JavaScript projects. Modern formatters read settings from these files. Single source of truth for tool configuration.

The Format vs Lint Distinction#

Formatter: Deterministic Transformation#

Input Code → Formatter → Output Code (always same)

Formatters answer: “How should this code look?”

• Indentation
• Line breaks
• Spacing around operators
• Quote style (single vs double)

Linter: Analysis and Warnings#

Input Code → Linter → Warnings/Errors (may vary by rule set)

Linters answer: “What might be wrong with this code?”

• Unused variables
• Potential bugs (== vs ===)
• Complexity warnings
• Security issues
• Best practice violations

Modern Trend: Unified Tools#

Traditional stack:

• Python: Black (format) + Flake8 (lint) + isort (imports)
• JavaScript: Prettier (format) + ESLint (lint)

Modern unified tools:

• Python: ruff (format + lint + imports)
• JavaScript: Biome (format + lint)

Benefit: Single tool, single config, faster execution.

The Performance Revolution#

Why Speed Matters#

Slow formatters create friction:

• Developers disable format-on-save (too slow)
• CI pipelines take longer (cost money)
• Large codebases become unusable (minutes to format)

The Rust Rewrite Phenomenon#

Many tools are being rewritten from Python/JavaScript to Rust:

• ruff (Rust) vs Black (Python): 30-100x faster
• Biome (Rust) vs Prettier (JS): 25x faster

Why Rust?

• Compiled language (no interpreter overhead)
• Excellent parallelization
• Memory efficiency
• Can still be called from Python/JS

Real-World Impact#

Configuration Philosophy Spectrum#

Fully Opinionated (Zero Config)#

Philosophy: One style. No debates. No config.

Example: Black

• 88 character line length (not 79, not 120)
• Double quotes (not single)
• No configuration for most decisions

Pro: Zero bikeshedding, instant adoption Con: Can’t customize to preferences

Partially Configurable#

Philosophy: Sensible defaults with limited options.

Example: Prettier

• Tab width: configurable (default 2)
• Quote style: configurable
• Trailing commas: configurable
• Most decisions: fixed

Pro: Balance of consistency and flexibility Con: Still some debate potential

Fully Configurable#

Philosophy: Every style decision is your choice.

Example: YAPF (Google’s Python formatter)

• Hundreds of configuration options
• Full control over every aspect

Pro: Perfect match to any style guide Con: Analysis paralysis, style debates return

Modern Consensus#

Industry has converged on opinionated formatters:

• Black’s success proved zero-config works
• Teams prefer “just works” over “perfect style”
• Time saved on debates > value of customization

The Import Sorting Problem#

Why It’s Separate#

Import statements have special ordering rules:

1. Standard library imports
2. Third-party imports
3. Local imports

Formatters traditionally didn’t handle this. Separate tools emerged:

• Python: isort
• JavaScript: ESLint import plugin

Modern Solution: Unified Tools#

ruff and Biome include import sorting:

• Same tool formats code AND sorts imports
• Single configuration
• Single CI step
• Single pre-commit hook

Common Misconceptions#

“Formatters slow down development”#

Reality: Format-on-save takes <100ms with modern tools. The time saved on style decisions far exceeds any formatting overhead.

“My style is better than the formatter’s”#

Reality: Consistency beats perfection. A codebase with one “wrong” style is better than a codebase with ten “right” styles.

“We need to customize everything”#

Reality: Configuration options create debates. Opinionated formatters eliminate this. Most teams are happier with zero-config.

“Linters and formatters do the same thing”#

Reality: Formatters change appearance. Linters analyze correctness. You need both (or a unified tool that does both).

Integration Patterns#

Development Workflow#

1. Developer writes code
2. IDE formats on save (instant feedback)
3. Pre-commit hook verifies (safety net)
4. CI check enforces (final gate)

CI/CD Integration#

# Example: Verify formatting in CI
- name: Check formatting
  run: |
    ruff format --check .
    ruff check .

Pre-commit Hook#

# .pre-commit-config.yaml
repos:
  - repo: https://github.com/astral-sh/ruff-pre-commit
    rev: v0.8.0
    hooks:
      - id: ruff-format
      - id: ruff

Build vs Buy: What’s “Free”#

All Major Tools Are Open Source#

• Black: MIT license
• ruff: MIT license
• Prettier: MIT license
• ESLint: MIT license
• Biome: MIT license

Hidden Costs#

Integration time: Setting up formatters, pre-commit, CI Migration effort: Reformatting entire codebase Team alignment: Getting everyone to use the same tools

Total Cost of Ownership#

Key Trade-offs#

Speed vs Maturity#

• Rust tools (ruff, Biome): 10-100x faster, younger
• Traditional tools (Black, Prettier): Slower, battle-tested

Unified vs Specialized#

• Unified tools: One config, one tool, some feature gaps
• Specialized tools: Best-in-class, more complexity

Opinionated vs Configurable#

• Opinionated: Fast adoption, no debates, no customization
• Configurable: Flexibility, but time spent on config

Summary: What Decision Makers Should Know#

1. Formatting is solved: Modern tools eliminate style debates entirely
2. Speed matters: Rust-based tools (ruff, Biome) are 10-100x faster
3. Unified beats specialized: One tool > three tools
4. Opinionated wins: Zero-config adoption beats configurable flexibility
5. CI integration is essential: Format checks should block merges

The 2025 Answer#

• Python: Use ruff (format + lint + imports, 30-100x faster)
• JavaScript/TypeScript: Prettier + ESLint (mature) or Biome (fast)
• Both: ruff + Prettier for mixed codebases

Research Disclaimer: This explainer provides educational context for code formatting concepts. For specific tool comparisons and recommendations, see the S1-S4 discovery research.

S1 Rapid Library Search: Code Formatting#

Research Domain: 1.104.2 Code Formatting Date Compiled: December 4, 2025 Methodology: S1 - Rapid Library Search (2-3 hours)

Quick Start#

Read recommendation.md first for actionable guidance.

Files#

Methodology#

• approach.md - S1 methodology explanation (88 lines)

Python Ecosystem#

• black.md - Established formatter standard (45 lines)
• ruff.md - Modern unified linter/formatter (64 lines) ⭐ RECOMMENDED
• autopep8.md - Legacy PEP 8 fixer (52 lines)
• yapf.md - Google’s configurable formatter (55 lines)
• isort.md - Import sorting tool (65 lines)
• blue.md - Black alternative with single quotes (60 lines)

JavaScript/TypeScript Ecosystem#

• prettier.md - Dominant formatter (64 lines) ⭐ RECOMMENDED
• eslint.md - Standard linter (84 lines) ⭐ RECOMMENDED
• biome.md - Unified Rust-based toolchain (88 lines) 🚀 EMERGING
• dprint.md - Rust-based performance formatter (86 lines)

Recommendations#

• recommendation.md - Comprehensive guidance by ecosystem (373 lines) ⭐ START HERE

Key Findings#

Python (Dec 2025)#

Ruff is replacing Black + isort + Flake8

• 30x faster than Black
• >99.9% Black compatibility
• Unified linting + formatting
• Major adoption: FastAPI, pandas, Apache Airflow

Safe Default: Ruff

JavaScript/TypeScript (Dec 2025)#

Prettier + ESLint remain dominant

• 55M weekly Prettier downloads
• 63M weekly ESLint downloads
• Mature ecosystem, predictable behavior

Emerging: Biome (97% Prettier compatibility, 391 ESLint rules, much faster)

Safe Default: Prettier + ESLint

Decision Tree#

Python Project?
├─ New → Use Ruff
├─ Existing Black → Migrate to Ruff
└─ Risk-averse → Keep Black

JavaScript/TypeScript Project?
├─ New + Simple → Consider Biome
├─ New + Complex → Prettier + ESLint
└─ Existing → Keep Prettier + ESLint

Research Scope#

Total lines: 1,124 across 12 files Time investment: ~2-3 hours (S1 Rapid methodology)

Next Steps#

• S2 (Comprehensive): Deep configuration analysis
• S3 (Need-Driven): Specific use case implementation
• S4 (Strategic): Long-term tooling strategy

S1 RAPID Library Search: Code Formatting#

Research Domain: 1.104.2 Code Formatting Methodology: S1 - Rapid Library Search Date Compiled: December 4, 2025 Time Investment: ~2-3 hours

Objective#

Speed-focused discovery of code formatting and linting libraries across Python and JavaScript/TypeScript ecosystems to determine current best practices and identify the dominant tools in each space.

Scope#

Python Ecosystem:

• Black (established formatter)
• Ruff (Rust-based formatter/linter)
• autopep8 (PEP 8 compliance)
• yapf (Google’s formatter)
• isort (import sorting)
• blue (Black alternative)

JavaScript/TypeScript Ecosystem:

• Prettier (dominant formatter)
• ESLint (linting standard)
• Biome (unified toolchain)
• dprint (Rust-based alternative)

Methodology: S1 Rapid Library Search#

The S1 approach prioritizes speed and ecosystem awareness over deep technical analysis:

1. Popularity Metrics (30 minutes)#

• GitHub stars (community adoption)
• Weekly downloads (npm/PyPI)
• Dependent packages
• Major project adoption

2. Quick Feature Assessment (45 minutes)#

• Primary purpose (formatting vs linting vs both)
• Performance claims (benchmarks if available)
• Key differentiator in 1-2 sentences
• Language/ecosystem support

3. Community Signals (30 minutes)#

• Recent release activity
• Backing organization (Astral, Google, Meta, etc.)
• Migration trends (what’s replacing what)
• Integration with modern tooling

4. Decision Framework (30 minutes)#

• When to use each tool
• Compatibility considerations
• Migration paths
• Future trajectory

Key Research Questions#

1. Is Ruff replacing Black? What’s the current state of Python formatting in late 2025?
2. Prettier dominance: Is Prettier still the default for JavaScript/TypeScript, or are alternatives gaining ground?
3. All-in-one tools: Are unified toolchains (Ruff, Biome) winning over single-purpose tools?
4. Performance matters: How much do speed improvements influence adoption?

Success Criteria#

• Quick verdict on each tool (50-100 words)
• Clear recommendation by ecosystem
• Understanding of migration trends
• Confidence in “safe default” choices

Limitations#

S1 research does NOT provide:

• Detailed configuration analysis
• Edge case behavior testing
• Plugin ecosystem deep-dives
• Custom rule implementation guides

For those needs, escalate to S2 (Comprehensive) or S3 (Need-Driven) methodologies.

Output Structure#

Each tool gets a dedicated markdown file with:

• Stars/downloads snapshot
• Key differentiator
• Performance notes
• Quick verdict

Final recommendation.md synthesizes findings into actionable guidance.

autopep8 - PEP 8 Compliance Formatter#

Ecosystem: Python Category: Code Formatter (PEP 8 focused) PyPI: https://pypi.org/project/autopep8/

Popularity Metrics (Dec 2025)#

• Downloads: Moderate (legacy tool)
• Ecosystem Position: Established but declining in favor of Black/Ruff

Key Differentiator#

autopep8 is a “loose formatter” that only fixes PEP 8 violations rather than enforcing a consistent style. If code is already PEP 8 compliant, autopep8 leaves it unchanged.

Philosophy: Minimal Changes#

Unlike Black or Ruff, autopep8 maintains the stylistic feel of the original code:

• Only modifies code that violates PEP 8
• Preserves developer’s formatting choices where compliant
• Focuses on fixing errors, not uniformity

Trade-off: Less consistency across developers, more manual style management.

Aggressive Mode#

Using the -a or --aggressive flag enables more extensive changes:

• Non-whitespace modifications
• More aggressive PEP 8 compliance
• Still less opinionated than Black

Use Cases#

Good for:

• Legacy codebases with established style
• Teams wanting minimal disruption
• Gradual migration toward PEP 8 compliance

Not ideal for:

• New projects (use Black or Ruff)
• Teams wanting consistent formatting
• Codebases needing uniform style

Quick Verdict#

Status: Legacy tool, superseded by Black/Ruff Best for: Conservative PEP 8 fixes without style enforcement Modern alternative: Ruff (comprehensive) or Black (opinionated)

autopep8 served an important role in Python’s formatting evolution but has been overtaken by opinionated formatters. Its “minimal change” philosophy conflicts with modern preferences for consistent, automated styling.

Recommendation: Avoid for new projects. Migrate to Black or Ruff for better consistency.

Biome - Unified Toolchain for Web Projects#

Ecosystem: JavaScript/TypeScript (multi-language) Category: Linter + Formatter (unified) Repository: https://github.com/biomejs/biome npm: https://www.npmjs.com/package/@biomejs/biome

Popularity Metrics (Dec 2025)#

• GitHub Stars: 20,000+ (estimated)
• Current Version: 2.3.8 (released 6 days ago)
• Dependent Projects: 223
• Written in: Rust

Key Differentiator#

Biome is a unified linter + formatter + import sorter written in Rust, aiming to replace the ESLint + Prettier + import sorting tool chain with a single, fast CLI tool.

Performance#

Biome is significantly faster than Node-based tools:

• Formatting: Faster than Prettier on 171,127 lines across 2,104 files
• Linting: 6s vs ESLint’s 15s (with type-aware rules)
• Type inference: 85% coverage of typescript-eslint at fraction of performance cost
• Rust-based execution eliminates Node.js overhead

Compatibility#

• Prettier: 97% compatibility
• ESLint rules: 391 rules from ESLint, TypeScript ESLint, and other sources
• Language support: JavaScript, TypeScript, JSX, TSX, JSON, HTML, CSS, GraphQL

Biome v2.0 (June 2025)#

Major milestone adding type inference:

• Catches type-related issues without TypeScript compiler
• Scans .d.ts files in node_modules
• ~85% coverage of typescript-eslint type checking
• Transitive dependency analysis

What Biome Replaces#

All-in-one toolchain:

• ESLint → Biome linter
• Prettier → Biome formatter
• Import sorters → Biome import sorting
• JSON/CSS formatting → Built-in support

Limitations#

Plugin Ecosystem:

• ESLint has 10+ years of plugin maturity
• Biome’s plugin ecosystem is growing but not comprehensive
• Missing some framework-specific linting (Vue SFCs, Angular templates)
• CSS, SCSS, YAML, Markdown support improving but not complete

Coverage Gaps:

• 85% type inference vs 100% with typescript-eslint
• Fewer rules than ESLint’s full ecosystem
• Less mature configuration patterns

Use Cases#

Good for:

• New projects (especially with Vite)
• Performance-critical tooling
• Simple linting requirements
• Teams wanting unified toolchain
• Monorepos needing speed

Not ideal for:

• Projects requiring advanced ESLint plugins
• Complex framework-specific linting
• Teams with heavily customized ESLint configs
• Vue/Angular projects needing template linting

Quick Verdict#

Status: Fast-growing alternative, not yet replacement Best for: New projects prioritizing performance and simplicity Trade-off: Speed + simplicity vs plugin ecosystem maturity

Biome represents the Rust-based future of JavaScript tooling - fast, unified, and simple. While it can’t fully replace ESLint + Prettier today (plugin gap), it’s a strong choice for new projects with straightforward needs.

Recommendation:

• New projects with Vite/simple needs: Consider Biome
• Existing projects: Stick with ESLint + Prettier unless performance is critical
• Complex linting requirements: Wait for Biome’s ecosystem to mature

Black - The Uncompromising Python Code Formatter#

Ecosystem: Python Category: Code Formatter Repository: https://github.com/psf/black PyPI: https://pypi.org/project/black/

Popularity Metrics (Dec 2025)#

• GitHub Stars: 38,000+ (estimated from ecosystem position)
• Weekly Downloads: High volume (exact stats not retrieved)
• Current Version: 25.1.0
• Notable Users: pytest, Django, pandas, SQLAlchemy, Poetry, pytest, tox
• Organizations: Dropbox, Mozilla, Quora, Tesla, Lyft

Key Differentiator#

Black is “the uncompromising Python code formatter” - it makes all formatting decisions for you with zero configuration. By ceding control over formatting details, teams gain consistency, speed, and freedom from style debates.

Features#

• Zero configuration by default (opinionated)
• Deterministic formatting (same code = same output)
• Black-compatible format has become an ecosystem standard
• PEP 8 compliant output
• Python 3.13 officially supported (Python 3.8 no longer supported)
• Fast formatting with mypyc-compiled wheels

Performance#

Black is reasonably fast for most projects but not as fast as Rust-based alternatives. Performance is adequate for pre-commit hooks on small-to-medium codebases.

2025 Stable Style#

The 2025 release introduced the new stable style, stabilizing various formatting changes that had been in preview. Black continues active development with regular releases.

Quick Verdict#

Status: Mature, widely adopted standard Best for: Teams wanting zero-configuration consistency and maximum ecosystem compatibility Consideration: Ruff format offers 30x faster formatting with >99.9% Black compatibility

Black remains the gold standard for Python formatting, but Ruff’s Black-compatible formatter is becoming the performance-focused alternative. Black’s “uncompromising” philosophy has successfully eliminated formatting debates across the Python ecosystem.

Recommendation: Safe default choice. Consider Ruff if speed matters or you want unified linting/formatting.

Blue - The Slightly Less Uncompromising Python Formatter#

Ecosystem: Python Category: Code Formatter Repository: https://github.com/grantjenks/blue PyPI: https://pypi.org/project/blue/

Popularity Metrics (Dec 2025)#

• GitHub Stars: ~300-400 (estimated, niche tool)
• Current Version: 0.9.1
• Origin: LinkedIn engineers
• Ecosystem Position: Niche Black alternative

Key Differentiator#

Blue is a Black fork with two opinionated changes: single-quoted strings (instead of double) and 79-character line lengths (instead of 88). Otherwise maintains Black’s philosophy.

Philosophy: Minimal Black Modifications#

Blue agrees with Black’s automatic formatting but disagrees with specific style choices:

• Single quotes for strings (except docstrings)
• 79-character line length (PEP 8 standard)
• Everything else stays Black-like

The team monkeypatches Black rather than forking the codebase, hoping to eventually merge configuration options back into Black.

Configuration Support#

Supports multiple config files:

• pyproject.toml
• setup.cfg
• tox.ini
• .blue

Why “Blue”?#

Named after LinkedIn’s brand color. The tool was created by LinkedIn engineers and socialized internally.

Use Cases#

Good for:

• Teams strongly preferring single quotes
• Projects strictly adhering to 79-character PEP 8 limit
• Organizations (like LinkedIn) with existing style preferences

Not ideal for:

• Ecosystem compatibility (Black is the standard)
• Projects wanting zero configuration debates
• Teams seeking maximum tool adoption

Quick Verdict#

Status: Niche tool, minimal adoption outside LinkedIn Best for: Teams with strong single-quote preference Trade-off: Customization vs ecosystem standardization

Blue demonstrates the tension between Black’s “uncompromising” philosophy and team preferences. While the modifications are minimal, they fragment the ecosystem. Black’s dominance (and Ruff’s Black compatibility) makes Blue’s use case increasingly narrow.

Recommendation: Avoid unless single quotes are non-negotiable. Use Black or Ruff for ecosystem alignment.

dprint - Pluggable Code Formatting Platform#

Ecosystem: Multi-language Category: Code Formatter Repository: https://github.com/dprint/dprint Website: https://dprint.dev/

Popularity Metrics (Dec 2025)#

• GitHub Stars: 3,000+ (estimated)
• Weekly Downloads: Low (niche tool)
• VS Code Downloads: 32 (v0.16.7, rated 4.8)
• Last Update: September 13, 2025
• Written in: Rust

Key Differentiator#

dprint is a Rust-based code formatter with no npm dependencies - just a standalone ~15MB binary. It’s 20-60x faster than Prettier via WebAssembly plugins and incremental formatting.

Performance#

Exceptional speed via Rust + incremental formatting:

• Small projects: 50-100ms vs Prettier’s 2-3 seconds (20-60x faster)
• Large codebases: <200ms vs Prettier’s 10+ seconds
• Pre-commit hooks: ~100ms for formatting (entire hook <1 second)
• Incremental: Only formats changed files by default

Architecture#

Plugin System:

• Plugins are WebAssembly files
• Imported from URL or file path
• Official plugins are highly configurable
• Multi-core CPU utilization by default

Language Support#

Via official plugins:

• TypeScript/JavaScript
• JSON
• Markdown
• TOML
• Dockerfile
• More via community plugins

Distribution#

No npm dependencies, just executable:

• Single ~15MB binary
• No Node.js runtime required
• Cross-platform (Linux, macOS, Windows)
• Can integrate with existing toolchains

Use Cases#

Good for:

• Performance-critical CI/CD pipelines
• Large monorepos
• Pre-commit hook optimization
• Rust-based toolchains
• Teams wanting minimal dependencies

Not ideal for:

• Standard JavaScript projects (Prettier is fine)
• Teams needing ecosystem compatibility
• Projects requiring extensive plugin ecosystem
• Organizations standardizing on well-known tools

Adoption Challenges#

Despite excellent performance, dprint faces adoption barriers:

• Prettier is “good enough” for most teams
• Limited community awareness
• Smaller plugin ecosystem
• Less IDE integration
• Not backed by major organization

Quick Verdict#

Status: Niche performance tool, limited adoption Best for: Performance-obsessed teams with large codebases Trade-off: Speed vs ecosystem maturity and familiarity

dprint solves Prettier’s performance problems elegantly but hasn’t achieved critical mass. For most teams, Prettier’s speed is adequate and its ecosystem integration outweighs dprint’s raw performance.

Recommendation: Consider only if Prettier’s performance is a genuine bottleneck (10+ second formatting). Otherwise, stick with Prettier’s mature ecosystem.

ESLint - Pluggable JavaScript Linter#

Ecosystem: JavaScript/TypeScript Category: Linter Repository: https://github.com/eslint/eslint npm: https://www.npmjs.com/package/eslint

Popularity Metrics (Dec 2025)#

• GitHub Stars: 26,279
• Weekly Downloads: 63,348,123 (63M+)
• Current Version: 9.36.0
• Annual Donations: $128,688 from 144 sponsors
• Repositories: 34 official ESLint repos

Key Differentiator#

ESLint is the #1 JavaScript linter by downloads, providing pluggable linting with extensive rule customization. While Prettier handles formatting, ESLint catches code quality issues, bugs, and anti-patterns.

Major Users#

• Microsoft
• Airbnb
• Netflix
• Facebook
• Countless open-source projects

ESLint vs Prettier: Division of Labor#

ESLint: Code quality and best practices

• Unused variables
• Missing dependencies
• Potential bugs
• Anti-patterns
• TypeScript-specific issues (via typescript-eslint)

Prettier: Code formatting

• Whitespace
• Line breaks
• Quotes
• Semicolons

These tools are complementary, not competitive.

TypeScript Support#

typescript-eslint provides comprehensive TypeScript linting:

• Type-aware rules
• TypeScript-specific checks
• Integration with TSC
• Growing ecosystem

Plugin Ecosystem#

ESLint’s killer feature is its mature plugin ecosystem:

• Framework-specific rules (React, Vue, Angular)
• Library-specific linting (Jest, Testing Library)
• Custom organizational rules
• Accessibility (jsx-a11y)
• Security scanning

Maturity: 10+ years of plugin development

2025 Status#

ESLint remains the standard for JavaScript/TypeScript linting. While Biome is emerging as an alternative, ESLint’s plugin ecosystem and decade of maturity make it the safe default.

Performance Considerations#

ESLint can be slow on large codebases, especially with type-aware rules:

• Type checking adds overhead
• Plugin chains compound execution time
• Biome offers 6s vs ESLint’s 15s on some codebases

Quick Verdict#

Status: Dominant standard, irreplaceable plugin ecosystem Best for: Any JavaScript/TypeScript project needing linting Pair with: Prettier for formatting Consider Biome: If performance is critical and you don’t need advanced plugins

ESLint’s combination of maturity, flexibility, and ecosystem support makes it the de facto linting standard. While newer tools offer performance improvements, none match ESLint’s breadth.

Recommendation: Default choice. Pair with Prettier for formatting. Consider Biome only for new projects with simple linting needs and performance requirements.

isort - Python Import Sorting#

Ecosystem: Python Category: Import Formatter Repository: https://github.com/PyCQA/isort PyPI: https://pypi.org/project/isort/

Popularity Metrics (Dec 2025)#

• GitHub Stars: 6,000+ (estimated)
• Ecosystem Position: Standard import sorting tool
• Python Support: Requires Python 3.9+, formats Python 2+ code

Key Differentiator#

isort is a dedicated utility for sorting Python imports alphabetically and automatically separating them into sections by type, following PEP 8 guidelines.

Features#

• Alphabetically sorts imports
• Automatically separates into sections (stdlib, third-party, local)
• Organizes by type
• Command-line utility + Python library
• Editor plugins available

Configuration Files#

Supports multiple configuration sources:

• pyproject.toml
• setup.cfg
• tox.ini
• .isort.cfg

Black Compatibility#

Important: Black and isort can conflict over formatting.

Solution: Always configure isort to use Black’s style profile:

[tool.isort]
profile = "black"

This ensures the two tools work together harmoniously.

Modern Alternative: Ruff#

Ruff includes isort functionality built-in:

• Same import sorting capability
• Integrated with linting and formatting
• Much faster (Rust-based)
• No separate configuration needed

Quick Verdict#

Status: Mature, widely used, but being absorbed into unified tools Best for: Projects already using isort or needing standalone import sorting Modern alternative: Ruff (includes isort functionality)

isort pioneered automatic import sorting and remains the standalone standard. However, Ruff’s inclusion of isort-compatible import sorting means new projects can avoid separate tools.

Recommendation:

• Existing projects: Keep isort with Black profile
• New projects: Use Ruff’s integrated import sorting
• Migration: Ruff can replace isort without changing behavior

Prettier - Opinionated Code Formatter#

Ecosystem: JavaScript/TypeScript (multi-language) Category: Code Formatter Repository: https://github.com/prettier/prettier npm: https://www.npmjs.com/package/prettier

Popularity Metrics (Dec 2025)#

• GitHub Stars: 50,922
• Weekly Downloads: 54,993,228 (55M+)
• Monthly Downloads: 218M (mid-2025 peak)
• Dependent Packages: 19,400+
• Current Version: 3.6.2

Key Differentiator#

Prettier is the opinionated code formatter that established the “stop debating formatting” philosophy for JavaScript. It enforces consistent style by parsing code and re-printing with its own rules, wrapping at max line length.

Supported Languages#

Extensive multi-language support:

• JavaScript, TypeScript, Flow, JSX
• JSON
• CSS, SCSS, Less
• HTML, Vue, Angular
• GraphQL
• Markdown
• YAML

Adoption#

With 55M weekly downloads and 19,400+ dependent packages, Prettier is the undisputed standard for JavaScript/TypeScript formatting. Nearly every major framework and tool ecosystem expects Prettier.

Performance#

Prettier is adequate for most projects but can be slow on large codebases:

• 2-3 seconds for small projects
• 10+ seconds for large monorepos
• Pre-commit hooks: 1-2 seconds for staged files

Faster alternatives: Biome (Rust), dprint (Rust)

Philosophy: Opinionated Consistency#

• Zero configuration by default
• Maximum line length awareness
• Deterministic output
• IDE and editor integration
• Git hooks compatibility

2025 Status#

Prettier remains the ecosystem default with no serious challengers threatening its dominance. While Biome and dprint offer performance improvements, Prettier’s maturity, language support, and ecosystem integration keep it as the standard.

Quick Verdict#

Status: Dominant standard, mature ecosystem Best for: Any JavaScript/TypeScript project Consider alternatives: Only if performance is critical (Biome) or you need multi-language Rust tooling (dprint)

Prettier achieved what Black later did for Python - eliminated formatting debates by making opinionated, deterministic choices. Its multi-language support and ecosystem integration make it the safe default.

Recommendation: Default choice for JavaScript/TypeScript. No reason to choose differently unless specific performance or toolchain requirements exist.

Code Formatting Recommendations by Ecosystem#

Research Date: December 4, 2025 Methodology: S1 Rapid Library Search Research Domain: 1.104.2 Code Formatting

Executive Summary#

The code formatting landscape has consolidated around opinionated, zero-configuration tools. Two major trends define late 2025:

1. Rust-based unified toolchains are displacing single-purpose tools (Ruff, Biome)
2. Performance matters - 10-100x speedups are driving adoption

Key Finding: Ruff is replacing Black + isort + Flake8 in Python. Prettier + ESLint remain dominant in JavaScript/TypeScript, but Biome is emerging for new projects.

Python Ecosystem#

Default Recommendation: Ruff#

Why Ruff?

• 30x faster than Black with >99.9% compatibility
• Unified linting + formatting + import sorting
• Replaces Black, isort, Flake8, pyupgrade, autoflake
• 800+ built-in rules
• Backed by Astral (creators of uv)
• Major adoption: FastAPI, pandas, Apache Airflow, pydantic

Migration Path:

# Replace Black + isort + Flake8
ruff format .  # Black-compatible formatting
ruff check .   # Comprehensive linting

Configuration: Black-compatible by default. Minimal config needed.

Alternative: Black#

Use Black if:

• Maximum ecosystem compatibility is critical
• Team is risk-averse about new tools
• Ruff’s 0.1% formatting differences matter
• You want the most battle-tested formatter

Black remains a safe choice with 38,000+ stars and adoption across pytest, Django, pandas, and SQLAlchemy. It’s mature, stable, and well-understood.

Legacy Tools to Avoid#

autopep8: Only fixes PEP 8 violations without enforcing consistency. Use Ruff or Black instead.

YAPF: Configurable but slower and less adopted. Black’s “uncompromising” philosophy won.

blue: Niche Black fork for single quotes. Fragments ecosystem without meaningful benefit.

isort: Standalone import sorting is obsolete - use Ruff’s integrated import sorting.

JavaScript/TypeScript Ecosystem#

Default Recommendation: Prettier + ESLint#

Why Prettier?

• 55M weekly downloads (dominant standard)
• 97% of projects expect Prettier formatting
• Multi-language: JS/TS/JSX, CSS, HTML, JSON, Markdown, YAML
• Opinionated, zero-config consistency
• Mature IDE integration

Why ESLint?

• 63M weekly downloads (linting standard)
• 10+ years of plugin ecosystem maturity
• Type-aware rules via typescript-eslint
• Framework-specific linting (React, Vue, Angular)
• Security and accessibility rules

Configuration:

// .eslintrc - Disable formatting rules (let Prettier handle)
{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier"  // Disables ESLint formatting rules
  ]
}

Division of Labor:

• Prettier: Formatting (whitespace, quotes, semicolons)
• ESLint: Code quality (unused vars, bugs, best practices)

Emerging Alternative: Biome#

Consider Biome if:

• Starting a new project (especially with Vite)
• Performance is critical (6s vs ESLint’s 15s)
• Simple linting needs (391 rules sufficient)
• Want unified toolchain (no Prettier + ESLint coordination)

Don’t use Biome if:

• Need advanced ESLint plugins
• Vue/Angular template linting required
• Complex framework-specific rules
• Team has heavily customized ESLint configs

Biome Status (Dec 2025):

• 97% Prettier compatibility
• 391 ESLint-compatible rules
• Type inference (85% of typescript-eslint)
• Growing but not mature plugin ecosystem

Niche Performance Tool: dprint#

Consider dprint only if:

• Prettier takes 10+ seconds on your codebase
• Pre-commit hooks are painfully slow
• You’re building Rust-based toolchain

Reality check: Prettier’s 2-3 seconds is adequate for 95% of projects. dprint’s 20-60x speedup rarely justifies adoption friction.

Decision Matrix#

Python Projects#

JavaScript/TypeScript Projects#

Cross-Language Considerations#

Monorepo with Python + JavaScript/TypeScript#

Recommended Stack:

Python: Ruff (format + lint)
JS/TS:  Prettier (format) + ESLint (lint)

Alternative (performance-focused):

Python: Ruff (format + lint)
JS/TS:  Biome (format + lint)

CI/CD Pipeline Optimization#

Speed matters in CI:

• Use Ruff for Python (0.4s vs Black’s ~3s)
• Consider Biome for JS/TS (6s vs 15s with ESLint)
• Pre-commit hooks benefit from incremental formatting

Caching Strategy:

# GitHub Actions - Cache formatter dependencies
- uses: actions/cache@v3
  with:
    path: ~/.cache/ruff
    key: ruff-${{ hashFiles('**/pyproject.toml') }}

The “Is Ruff Replacing Black?” Question#

Answer: Yes, increasingly.

Evidence:

• Major projects migrated: FastAPI, pandas, Apache Airflow, pydantic
• Pylint uses Ruff as pre-commit hook
• Astral backing (uv creators) ensures long-term support
• >99.9% Black compatibility eliminates risk
• 30x speed improvement is compelling

Timeline:

• 2024: Ruff gains formatter capability
• 2025: Rapid adoption across major projects
• 2026 (projected): Ruff becomes default for new Python projects

Black’s Future: Black isn’t going away - it remains maintained and widely used. But Ruff represents the next generation: Rust-based, unified, and dramatically faster.

Recommendation: Use Ruff for new projects. Migrate existing Black setups when convenient.

The “Is Biome Replacing Prettier + ESLint?” Question#

Answer: Not yet, but momentum building.

Evidence for Biome:

• 97% Prettier compatibility
• 391 ESLint-compatible rules
• Significant performance improvements
• Strong with modern tooling (Vite)
• Type inference without TSC overhead

Evidence against Biome:

• Prettier + ESLint have 10+ years of maturity
• Plugin ecosystem gap remains significant
• Framework support (Vue, Angular) incomplete
• Most projects “good enough” with current tools

Timeline:

• 2024: Biome v2.0 adds type inference
• 2025: Growing adoption in new projects
• 2026+ (projected): Biome matures, plugin gap narrows

Recommendation: Watch Biome closely. Consider for new projects with simple needs. Stick with Prettier + ESLint for complex requirements.

Configuration Examples#

Python with Ruff#

# pyproject.toml
[tool.ruff]
line-length = 88  # Black default
target-version = "py311"

[tool.ruff.format]
quote-style = "double"  # Black-compatible
indent-style = "space"

[tool.ruff.lint]
select = ["E", "F", "I"]  # pycodestyle, Pyflakes, isort
ignore = ["E501"]  # Line too long (formatter handles)

# Pre-commit
[tool.ruff]
extend-exclude = ["migrations", "snapshots"]

JavaScript/TypeScript with Prettier + ESLint#

// .prettierrc
{
  "semi": true,
  "singleQuote": false,
  "tabWidth": 2,
  "trailingComma": "es5"
}

// .eslintrc.json
{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "prettier"
  ],
  "plugins": ["@typescript-eslint"],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "project": "./tsconfig.json"
  }
}

JavaScript/TypeScript with Biome#

// biome.json
{
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "lineWidth": 100
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "double",
      "semicolons": "always"
    }
  }
}

Final Recommendations by Team Size#

Solo Developer / Small Team (1-5 people)#

Python: Ruff (simplicity + speed) JS/TS: Prettier + ESLint (or Biome for simple projects)

Rationale: Minimize tool complexity, maximize consistency.

Medium Team (5-20 people)#

Python: Ruff (eliminate debate, enforce consistency) JS/TS: Prettier + ESLint (mature ecosystem, predictable)

Rationale: Team coordination benefits from opinionated defaults.

Large Team / Enterprise (20+ people)#

Python: Ruff (speed critical in CI/CD at scale) JS/TS: Prettier + ESLint (unless performance is bottleneck)

Rationale: Established tools reduce onboarding friction. Performance matters in large repos.

Migration Strategies#

Black → Ruff#

1. Install Ruff: uv add --dev ruff
2. Format codebase: ruff format .
3. Compare diff with Black: black . --check
4. Review differences (<0.1% of lines)
5. Update CI/CD configs
6. Remove Black, isort, Flake8

Risk: Minimal. >99.9% compatibility.

Prettier + ESLint → Biome#

1. Install Biome: npm install --save-dev @biomejs/biome
2. Initialize config: npx @biomejs/biome init
3. Migrate rules from ESLint (manual review)
4. Test on subset of files
5. Compare output with Prettier
6. Full codebase migration
7. Update CI/CD configs

Risk: Moderate. Plugin gaps may require keeping ESLint.

Conclusion#

Python (2025): Ruff is the modern default, replacing Black + isort + Flake8 with unified, blazing-fast tooling.

JavaScript/TypeScript (2025): Prettier + ESLint remain standard, but Biome is viable for new projects prioritizing simplicity and speed.

The Pattern: Rust-based unified toolchains are winning. Performance + simplicity + zero-config = developer joy.

Safe Defaults:

• Python: Ruff
• JavaScript/TypeScript: Prettier + ESLint
• Performance-critical JS/TS: Biome

Ruff - Extremely Fast Python Linter and Formatter#

Ecosystem: Python Category: Linter + Formatter (unified) Repository: https://github.com/astral-sh/ruff PyPI: https://pypi.org/project/ruff/ Maintainer: Astral (creators of uv)

Popularity Metrics (Dec 2025)#

• GitHub Stars: 25,000+
• Current Version: 0.14.7
• Major Adopters: Apache Airflow, FastAPI, pandas, pydantic, Pylint itself
• Built-in Rules: 800+ rules
• Written in: Rust

Key Differentiator#

Ruff is a unified linter and formatter written in Rust that replaces Black, isort, Flake8, pyupgrade, autoflake, and dozens of plugins - all while running 10-100x faster than any individual tool.

Performance Benchmarks#

• vs Black: 30x faster (even faster than Black with caching)
• vs Flake8: 10-100x faster
• vs YAPF: 100x faster
• Real-world: 0.2s for entire codebase vs 20s with Flake8
• dagster (250k LOC): 0.4s vs pylint’s 2.5 minutes

Black Compatibility#

Ruff’s formatter achieves >99.9% compatibility with Black. When formatting Django codebase, Ruff and Black differ on only 34 out of 2,772 files.

Known differences:

• Ruff formats f-string expressions inside {...}
• Ruff handles end-of-line comments differently to preserve intent
• Default config mimics Black (double quotes, spaces, magic trailing commas)

Features#

• Unified toolchain: Linting + formatting + import sorting in one tool
• Native re-implementations: Popular Flake8 plugins built-in
• Replaces: Black, isort, Flake8, pyupgrade, autoflake, pydocstyle, yesqa, eradicate
• Jupyter support: Formats and lints .ipynb files
• Python 3.14 support: Updated for latest Python releases

2025 Status: Is Ruff Replacing Black?#

Yes, increasingly. Major projects (FastAPI, pandas, Apache Airflow) have migrated to Ruff. The combination of:

• Black-compatible formatting
• Unified linting/formatting
• Extreme performance
• Active development by Astral

…makes Ruff the modern default for new Python projects.

Quick Verdict#

Status: Rapidly becoming the ecosystem default Best for: Any Python project wanting speed, unified tooling, and Black compatibility Migration: Drop-in Black replacement via ruff format

Ruff represents the new generation of Python tooling - Rust-based, unified, and extremely fast. While Black pioneered opinionated formatting, Ruff delivers the same philosophy with better performance and integrated linting.

Recommendation: Default choice for new projects. Strong candidate for migrating existing Black + Flake8 + isort setups.

YAPF - Yet Another Python Formatter#

Ecosystem: Python Category: Code Formatter Maintainer: Google Repository: https://github.com/google/yapf

Popularity Metrics (Dec 2025)#

• GitHub Stars: 13,000+ (estimated)
• Ecosystem Position: Niche tool for teams wanting configurability
• Origin: Google

Key Differentiator#

YAPF is a “strict formatter” like Black but with significant configurability. It comes with three built-in styles (pep8, google, chromium) and extensive customization options.

Philosophy: Configurable Formatting#

Unlike Black’s “uncompromising” approach:

• Highly configurable base styles
• Does not fix PEP 8 violations (just formats)
• Can beautify already-compliant code
• Balances consistency with team preferences

Readability Focus#

October 2025 analysis comparing Ruff, autopep8, and YAPF found:

• Best readability out of the box (only 1 tweak needed)
• Strange handling of long dictionaries (main complaint)
• Most readable code output among alternatives

Performance Concerns#

Weaknesses:

• Slower than Black (significantly slower than Ruff)
• Clunky CLI: yapf --inplace --recursive . vs Black’s black .
• Not Rust-based, so limited speed improvements

Built-in Styles#

• pep8: PEP 8 guidelines
• google: Google’s Python style guide
• chromium: Chromium project style
• facebook: Facebook’s internal style

Quick Verdict#

Status: Mature but niche Best for: Teams needing style customization beyond Black’s opinionated defaults Trade-off: Configuration complexity vs consistency guarantees

YAPF’s configurability is both strength and weakness. While it produces highly readable code and respects team preferences, the Python ecosystem has largely moved toward Black’s “no configuration” philosophy. Speed and simplicity win over customization.

Recommendation: Consider only if your team has strong, specific formatting requirements that Black/Ruff cannot accommodate. Otherwise, use Black or Ruff for simplicity and ecosystem alignment.

S2 Comprehensive Solution Analysis: Code Formatting Libraries#

Methodology Overview#

S2 Comprehensive Solution Analysis provides systematic evaluation of code formatting tools through multi-source discovery, weighted comparison matrices, and deep trade-off analysis. This methodology prioritizes evidence-based selection over superficial feature comparison.

Research Framework#

Multi-Source Discovery#

Primary Sources:

• Official documentation and benchmarks
• GitHub repositories (stars, commits, issues, PRs)
• Package registries (PyPI, npm) download statistics
• Performance benchmarks from tool maintainers
• Community adoption metrics (VS Code extensions, usage stats)

Secondary Sources:

• Migration guides from real-world teams
• Technical blog posts from practitioners
• Stack Overflow discussions and patterns
• Developer surveys (State of JS, Python Developers Survey)

Weighted Criteria Matrix#

Performance (35% weight):

• Formatting speed (lines/second)
• Memory consumption
• Incremental formatting support
• Cache effectiveness
• Startup time impact

Configuration (20% weight):

• Opinionated vs. configurable philosophy
• Configuration file format
• Rule customization depth
• Profile/preset support

Ecosystem Integration (25% weight):

• IDE support (VS Code, PyCharm, JetBrains)
• CI/CD pipeline integration
• Pre-commit hook compatibility
• Build tool integration
• Language server protocol support

Compatibility (20% weight):

• Migration path from existing tools
• Output consistency with popular formatters
• Breaking change frequency
• Backward compatibility guarantees
• Cross-platform behavior

Deep Trade-off Analysis#

Speed vs. Configurability#

High-speed, low-config: Black, Ruff formatter, Prettier

• Philosophy: “One obvious way to format”
• Trade-off: Faster adoption, less bike-shedding, limited customization
• Best for: Teams prioritizing consistency over style preferences

Moderate-speed, high-config: YAPF, autopep8, ESLint

• Philosophy: “Adapt to existing style guides”
• Trade-off: Flexible, but slower performance and decision fatigue
• Best for: Organizations with established style guides

Single Tool vs. Best-of-Breed#

Unified Toolchain: Ruff (format + lint), Biome (format + lint)

• Advantages: Single config, faster CI, fewer dependencies
• Disadvantages: Less mature, incomplete rule coverage
• Best for: New projects, performance-critical pipelines

Separate Tools: Black + Ruff linter, Prettier + ESLint

• Advantages: Battle-tested, comprehensive rule sets
• Disadvantages: Multiple configs, slower pipelines, integration complexity
• Best for: Established codebases, maximum control

Evaluation Process#

Stage 1: Initial Assessment (2-4 hours)#

1. Install and run each tool on sample codebases
2. Measure formatting speed on 10k, 100k, 1M line projects
3. Review official documentation completeness
4. Check IDE integration availability

Stage 2: Deep Analysis (4-8 hours)#

1. Create feature comparison matrix
2. Run performance benchmarks
3. Test migration scenarios
4. Evaluate configuration complexity
5. Assess community health (GitHub activity, release cadence)

Stage 3: Trade-off Documentation (2-4 hours)#

1. Document speed/flexibility trade-offs
2. Identify compatibility concerns
3. Map tool combinations (formatter + linter strategies)
4. Create decision trees for different scenarios

Stage 4: Recommendation Synthesis (2-3 hours)#

1. Weight criteria based on common scenarios
2. Provide guidance for different team sizes/maturity
3. Include migration considerations
4. Document edge cases and limitations

Evidence-Based Selection Principles#

Quantitative Metrics:

• Performance benchmarks (lines/second)
• Adoption statistics (downloads, GitHub stars)
• Compatibility percentages (vs. reference formatter)
• Breaking change frequency

Qualitative Assessment:

• Developer experience reports
• Migration difficulty
• Documentation quality
• Community responsiveness

Decision Factors:

• Team size and structure
• Codebase size and growth trajectory
• Existing toolchain integration
• Performance requirements
• Configuration flexibility needs

Output Deliverables#

1. Tool Deep Dives: Detailed analysis per tool (100-150 lines each)
2. Feature Matrix: Comparative table across all dimensions
3. Performance Benchmarks: Speed comparisons with methodology
4. Recommendation Guide: Decision framework for selection
5. Migration Paths: Guides for transitioning between tools

Success Criteria#

• Comprehensive coverage of mainstream formatters (90%+ market share)
• Quantitative performance data for all tools
• Clear decision frameworks for different scenarios
• Migration guidance between major tools
• Trade-off documentation for key decisions

Biome: Fast, Unified Formatter and Linter for JavaScript/TypeScript#

Overview#

Biome is a performant, all-in-one toolchain for JavaScript, TypeScript, JSX, JSON, and CSS. Designed as a unified replacement for Prettier (formatting) and ESLint (linting), Biome delivers 25x faster formatting and 15x faster linting through its Rust-based architecture and multi-threading capabilities.

Current Status: Production-ready, rapidly maturing Written In: Rust License: MIT First Release: 2023 (forked from Rome project) Latest Version: 2.x (as of December 2025) Company: Community-driven (originally Rome, now independent)

Core Philosophy#

Biome’s philosophy: unified, fast, and practical tooling that replaces multiple JavaScript tools with a single, performant solution.

Design Principles:

• Unified toolchain (formatter + linter in one tool)
• Extreme performance (Rust + multi-threading)
• Prettier compatibility (~97%)
• Single configuration file (biome.json)
• Modern architecture for modern JavaScript

Goals:

• Replace Prettier + ESLint with one tool
• Provide consistent, fast developer experience
• Minimize configuration complexity
• Support plugin system (Biome 2.0+)

Architecture#

Two Primary Functions:

1. biome format - Code formatting

   • ~97% compatible with Prettier
   • Multi-threaded (25x faster on multi-core systems)
   • Supports JS, TS, JSX, TSX, JSON, CSS

2. biome lint - Linting and auto-fixing

   • Covers many ESLint rules
   • Includes TypeScript ESLint equivalents
   • Accessibility rules (JSX A11y)
   • React-specific rules
   • Auto-fix capabilities

3. biome check - Combined format + lint

   • Single command for both operations
   • Optimal performance (shared AST)

Performance Characteristics#

Formatter Benchmarks:

• 25x faster than Prettier (multi-threaded)
• 100x faster on M1 Max with 10 cores
• 7x faster single-threaded
• Real-world: 1.3s vs. 28s for 312 files (20x speedup)

Linter Benchmarks:

• 15x faster than ESLint (without plugins)
• 4x faster even single-threaded
• Faster than ESLint with extensive caching

Why So Fast:

• Written in Rust (memory safety, no GC pauses)
• Multi-threaded by default
• Optimized parser (shared across format/lint)
• Incremental processing (planned)
• Zero npm dependencies

Performance Impact:

• Pre-commit hooks: instant instead of seconds
• CI pipelines: seconds instead of minutes
• Watch mode: near-instantaneous feedback

Language Support#

First-Class Support:

• JavaScript (ES5-ES2024+)
• TypeScript
• JSX/TSX (React)
• JSON/JSONC
• CSS (experimental)

Limited/Experimental:

• GraphQL (in progress)
• Vue (limited support)
• Markdown (limited)
• YAML (not supported)

Not Supported:

• HTML (use Prettier)
• PHP, Ruby, Python (use language-specific tools)

Prettier Compatibility#

Compatibility Level:

• ~97% compatible with Prettier output
• Biome won the “Prettier Challenge” (official recognition)
• Most projects can migrate with minimal diff

Known Differences:

• Default quote style (configurable)
• Some edge cases in JSX formatting
• Comment placement subtleties
• Line break decisions in complex expressions

Migration Command:

npx biome migrate prettier --write

Automatically converts .prettierrc to biome.json

ESLint Compatibility#

Covered Rule Categories:

• ESLint core rules (many implemented)
• TypeScript ESLint (@typescript-eslint)
• JSX A11y (accessibility)
• React rules (react-hooks, etc.)
• Unicorn plugin (flake8-like checks)

Not Covered:

• 1000+ community ESLint plugins
• Framework-specific plugins (Vue, Angular specific)
• Custom company/team plugins

Migration Tool:

npx biome migrate eslint --write

Converts compatible ESLint rules to Biome configuration

Configuration#

Single Configuration File:

• biome.json or biome.jsonc
• Consolidates formatting, linting, and file patterns
• Simpler than separate ESLint + Prettier configs

Example Configuration:

{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true,
      "complexity": {
        "noExtraBooleanCast": "error"
      },
      "style": {
        "useConst": "warn"
      }
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "semicolons": "asNeeded",
      "trailingCommas": "es5"
    }
  }
}

Configuration Options:

Formatter:

• lineWidth (like Prettier’s printWidth)
• indentStyle, indentWidth
• quoteStyle (single, double)
• semicolons (always, asNeeded)
• trailingCommas

Linter:

• Rule-by-rule configuration
• Severity levels (error, warn, off)
• Ignore patterns per rule

IDE and Ecosystem Integration#

IDE Support:

• VS Code: Official Biome extension (fast LSP-based)
• WebStorm: Plugin available (community)
• Neovim: nvim-lspconfig support
• Vim: Basic support
• Emacs: Limited support

VS Code Integration:

{
  "[javascript]": {
    "editor.defaultFormatter": "biomejs.biome"
  },
  "[typescript]": {
    "editor.defaultFormatter": "biomejs.biome"
  },
  "editor.codeActionsOnSave": {
    "quickfix.biome": "explicit",
    "source.organizeImports.biome": "explicit"
  }
}

CI/CD Integration:

• GitHub Actions: Community actions available
• Pre-commit: biome hook
• Simple CLI for any CI system

Commands:

# Check and fix everything
biome check --write .

# Format only
biome format --write .

# Lint only
biome lint --write .

# CI check (no fixes)
biome ci .

Strengths#

Performance:

• 25x faster formatting (multi-threaded)
• 15x faster linting
• Transforms slow CI into instant feedback
• Critical for large monorepos

Unified Toolchain:

• One tool replaces Prettier + ESLint
• Single configuration file
• Shared AST (faster, consistent)
• Reduced npm dependencies

Prettier Compatibility:

• 97% compatible output
• Easy migration path
• Official migration tools
• Recognized by Prettier maintainers

Developer Experience:

• Fast LSP-based editor integration
• Clear error messages
• Auto-fix capabilities
• Modern CLI design

Modern Architecture:

• Rust-based (safe, fast)
• Multi-threaded by default
• Plugin system (Biome 2.0+)
• Active development

Limitations#

Language Coverage:

• JS/TS/JSON/CSS only (no HTML, YAML, Markdown formatting)
• Need Prettier for additional languages
• Vue, Svelte support limited

Rule Coverage:

• Not all ESLint plugins covered (~200 rules vs. ESLint’s 1000+)
• Custom company plugins not available
• Gap shrinking but not complete

Maturity:

• Newer than Prettier/ESLint (less battle-tested)
• Some edge cases still being discovered
• Smaller community and ecosystem

Configuration Format:

• JSON/JSONC only (no JS config files)
• Less flexible for dynamic configuration
• Cannot use environment variables easily

Incremental Formatting:

• No incremental formatting (formats full files)
• Prettier supports this, Biome does not yet

Use Cases#

Ideal For:

• New JavaScript/TypeScript projects
• Large monorepos with slow CI
• Teams wanting to simplify toolchain
• Projects primarily using JS/TS (not multi-language)
• Performance-critical development workflows

Less Ideal For:

• Projects requiring HTML/YAML/Markdown formatting
• Teams with extensive custom ESLint plugins
• Conservative organizations (Prettier/ESLint more mature)
• Multi-language projects (JS + Python + Ruby, etc.)

Migration Strategy#

From Prettier + ESLint:

Phase 1: Assessment

# Test Biome on codebase
npx @biomejs/biome check --write .

# Review differences
git diff

Phase 2: Migration

# Migrate configs
npx @biomejs/biome migrate prettier --write
npx @biomejs/biome migrate eslint --write

# Install Biome
npm install --save-dev @biomejs/biome

# Remove old tools
npm uninstall prettier eslint eslint-plugin-*

Phase 3: Integration

• Update VS Code settings
• Update pre-commit hooks
• Update CI scripts
• Document for team

Expected Impact:

• ~3% line changes from Prettier differences
• Some ESLint rules may not have equivalents
• Significant CI speed improvement

Biome 2.0 Features#

Plugin System:

• Allow custom rules (like ESLint plugins)
• Community-developed plugins
• Framework-specific extensions

Enhanced Language Support:

• Improved CSS support
• GraphQL formatting
• Potential HTML support

Performance:

• Incremental formatting/linting
• Even faster multi-threading
• Caching improvements

Recommended Workflows#

Standard Commands:

# Format and lint everything
biome check --write .

# CI check (no modifications)
biome ci .

# Format only
biome format --write .

# Lint only
biome lint --write .

Package.json Scripts:

{
  "scripts": {
    "format": "biome format --write .",
    "lint": "biome lint --write .",
    "check": "biome check --write .",
    "ci": "biome ci ."
  }
}

Pre-commit Hook:

repos:
  - repo: local
    hooks:
      - id: biome
        name: Biome
        entry: npx @biomejs/biome check --write --no-errors-on-unmatched --files-ignore-unknown=true
        language: system
        types: [javascript, typescript, jsx, tsx, json]
        pass_filenames: true

Comparison Summary#

vs. Prettier:

• Biome: 25x faster, JS/TS only, 97% compatible, includes linting
• Prettier: Multi-language, mature, slower

vs. ESLint:

• Biome: 15x faster, fewer rules, unified with formatter
• ESLint: 1000+ rules, highly configurable, slower

vs. Ruff (Python):

• Similar philosophy: Rust-based, unified, fast
• Different ecosystems (JS vs. Python)

Community and Maintenance#

Maturity: Young but rapidly maturing (2 years) Activity: Very active development GitHub Stars: ~15,000+ Maintainers: Community-driven, multiple core contributors Release Cadence: Frequent releases (weekly/bi-weekly)

Verdict#

Biome represents the future of JavaScript tooling: fast, unified, and practical. Its 25x formatting speed and 15x linting speed make it ideal for large projects and performance-conscious teams. With 97% Prettier compatibility and growing ESLint rule coverage, Biome is ready for production use.

Choose Biome if:

• You want maximum performance (large monorepo, slow CI)
• You’re starting a new JS/TS project
• You want to simplify toolchain (one tool vs. two)
• Your project is primarily JS/TS (not multi-language)

Stick with Prettier + ESLint if:

• You need multi-language formatting (HTML, YAML, Markdown)
• You rely on specific ESLint plugins not in Biome
• You prefer maximum maturity and stability
• You have complex dynamic ESLint configurations

Hybrid Approach:

• Biome for JS/TS formatting + linting
• Prettier for HTML/Markdown/YAML
• Best of both worlds

By 2025, Biome has gained significant traction, with many teams migrating for performance gains. The upcoming plugin system (Biome 2.0) will likely accelerate adoption further.

Black: The Uncompromising Python Code Formatter#

Overview#

Black is the most popular Python code formatter, pioneering the “opinionated formatter” philosophy in the Python ecosystem. Released in 2018, it has become the de facto standard for Python code formatting, adopted by major projects including Django, pytest, Requests, and thousands of others.

Current Status: Mature, stable, industry standard Written In: Python License: MIT First Release: 2018 Latest Version: 25.11.0 (as of December 2025)

Core Philosophy#

Black follows the “uncompromising” philosophy: one obvious way to format Python code. This eliminates bike-shedding discussions about code style within teams.

Design Principles:

• Minimal configuration (by design)
• PEP 8 compliant
• Deterministic formatting
• Near-zero diff churn on reformatting
• Fast enough for pre-commit hooks

The Black Code Style:

• 88 character line length (default)
• Double quotes for strings
• Vertical whitespace optimization
• Trailing commas in multi-line constructs
• Magic trailing comma for list splitting

Performance Characteristics#

Speed Benchmarks:

• ~250,000 lines: 1-3 seconds (without cache)
• ~250,000 lines: <1 second (with cache)
• Baseline for Python formatter comparisons

Performance Features:

• File-level caching (.black cache)
• Incremental formatting
• Multi-file parallel processing (with –fast option)
• AST-based parsing (safe, preserves semantics)

Startup Time:

• ~100-200ms startup overhead (Python interpreter)
• Noticeable in pre-commit hooks on small files
• Less impactful on large codebases

Configuration#

Black deliberately provides minimal configuration to enforce consistency:

Configurable Options:

• line-length (default 88)
• target-version (Python version: py37, py38, py39, etc.)
• skip-string-normalization (keep quote style)
• skip-magic-trailing-comma (disable trailing comma logic)
• include/exclude patterns

Configuration Files:

• pyproject.toml (preferred)
• .black (legacy)
• Command-line arguments

Example Configuration:

[tool.black]
line-length = 88
target-version = ['py311']
include = '\.pyi?$'
exclude = '''
/(
    \.git
  | \.venv
  | build
  | dist
)/
'''

IDE and Ecosystem Integration#

IDE Support (Excellent):

• VS Code: Official extension + Python extension support
• PyCharm: Built-in integration (Code | Reformat with Black)
• Vim/Neovim: vim-black plugin
• Emacs: python-black package
• Sublime Text: sublack plugin

CI/CD Integration:

• GitHub Actions: psf/black action
• Pre-commit: Official hook (black)
• tox: Easy integration
• GitLab CI, CircleCI: Simple command execution

Language Server Protocol:

• Black Formatter extension (v22.3.0+)
• Faster formatting via LSP server
• Real-time feedback in editors

Compatibility and Migration#

PEP 8 Compliance:

• Fully compliant with PEP 8
• Makes opinionated choices where PEP 8 is flexible
• More aggressive than minimal PEP 8 compliance

Migration Considerations:

• Initial reformatting creates large diffs
• Recommend reformatting on separate commit
• Use # fmt: off / # fmt: on for exceptions
• --check mode for CI validation without reformatting

Compatibility with Other Tools:

• Works well with ruff linter
• Compatible with isort (with profile = "black")
• Integrates with mypy, pylint (no conflicts)

Strengths#

Consistency:

• Zero configuration decisions = zero debates
• Same output across all team members
• Deterministic across versions (minimal breaking changes)

Adoption:

• Industry standard (highest PyPI downloads for formatters)
• Extensive documentation and community support
• Many teams already using it

Safety:

• AST-based formatting (never breaks code)
• Extensive test suite
• Conservative release cycle

Tooling:

• Excellent IDE integration
• Simple pre-commit setup
• Well-documented APIs for custom integrations

Limitations#

Performance:

• 30-100x slower than Ruff formatter
• Startup time noticeable in pre-commit hooks
• Python-based (GIL limitations on parallelization)

Configurability:

• Deliberately minimal options
• Cannot adapt to existing style guides
• No per-file configuration overrides

String Formatting:

• Double quote default annoys some developers
• skip-string-normalization disables all normalization

Line Length:

• 88 character default controversial for some teams
• Cannot configure different lengths for different contexts

Use Cases#

Ideal For:

• New Python projects starting fresh
• Teams wanting to eliminate style debates
• Organizations with multiple Python projects
• Open source projects seeking consistency

Less Ideal For:

• Projects with strict existing style guides (e.g., Google style)
• Performance-critical CI pipelines
• Teams requiring extensive formatting customization
• Large monorepos with slow pre-commit hooks

Community and Maintenance#

Maturity: Very mature (7+ years) Activity: Active development, stable release cycle GitHub Stars: ~38,000+ Maintainers: Python Software Foundation Release Cadence: Monthly minor releases, annual major releases

Community Size:

• Extensive Stack Overflow presence
• Active GitHub discussions
• Multiple integrations and plugins

Comparison Context#

vs. Ruff Formatter:

• Black: Industry standard, mature, slower
• Ruff: >99.9% compatible, 30x faster, newer

vs. autopep8:

• Black: Opinionated, consistent output
• autopep8: Minimal changes, PEP 8 focused only

vs. YAPF:

• Black: Fast, minimal config
• YAPF: Configurable, slower, Google-style support

Recommended Combination#

Standard Setup:

# Format with Black
black .

# Lint with ruff
ruff check --fix .

# Sort imports with ruff
ruff check --select I --fix .

pyproject.toml:

[tool.black]
line-length = 88
target-version = ['py311']

[tool.ruff]
line-length = 88

[tool.ruff.lint]
select = ["E", "F", "I"]

Verdict#

Black remains the gold standard for Python formatting in 2025. Its opinionated approach has successfully eliminated code style debates across thousands of projects. While newer alternatives like Ruff offer significant speed improvements, Black’s maturity, stability, and universal adoption make it a safe, reliable choice.

Choose Black if: You want the industry-standard formatter with maximum compatibility and tooling support. Consider alternatives if: CI performance is critical or you need a unified linter/formatter toolchain.

ESLint: Pluggable JavaScript and TypeScript Linter#

Overview#

ESLint is the most popular and comprehensive linting tool for JavaScript and TypeScript. Unlike formatters (Prettier, Biome), ESLint focuses on code quality, bug detection, and best practices enforcement. It provides a highly configurable, plugin-based architecture with 1000+ rules and extensive community ecosystem.

Current Status: Mature, industry standard Written In: JavaScript License: MIT First Release: 2013 Latest Version: 9.x (as of December 2025) Monthly Downloads: ~60 million (npm)

Core Philosophy#

ESLint’s philosophy: Pluggable linting that allows teams to enforce code quality standards, detect bugs, and maintain best practices through configurable rules.

Design Principles:

• Pluggable architecture (custom rules, plugins)
• Highly configurable (per-project, per-file)
• AST-based analysis (safe, semantic-aware)
• Auto-fix capabilities where possible
• Language agnostic (via parsers)

Focus Areas:

• Code quality (complexity, patterns)
• Bug detection (potential errors)
• Best practices (modern JS/TS patterns)
• Style consistency (though Prettier preferred for formatting)

ESLint vs. Formatters#

Key Distinction:

ESLint (Linter):

• Finds problematic code patterns
• Enforces best practices
• Detects potential bugs
• Can fix some issues automatically
• Configurable style rules (discouraged)

Prettier/Biome (Formatters):

• Formats code appearance
• Enforces consistent style
• Opinionated formatting
• No bug detection
• Minimal configuration

Recommended Approach:

• Use Prettier/Biome for formatting
• Use ESLint for linting/quality
• Disable ESLint formatting rules (eslint-config-prettier)

Architecture#

Core Components:

1. Parser: Converts code to AST

   • Default: espree (JavaScript)
   • @typescript-eslint/parser (TypeScript)
   • @babel/eslint-parser (Babel features)

2. Rules: Individual checks (400+ built-in)

   • Errors, warnings, suggestions
   • Auto-fixable vs. manual

3. Plugins: Rule collections and extensions

   • Community plugins (1000+)
   • Framework-specific (React, Vue, Angular)
   • Tool-specific (Jest, Testing Library)

4. Configs: Shareable rule configurations

   • eslint:recommended
   • Airbnb, Google, Standard
   • Company/team configs

Performance Characteristics#

Speed Benchmarks:

• Single-threaded execution
• Moderate speed (JavaScript-based)
• Can be slow with many plugins
• Caching helps significantly

Performance Issues:

• Large codebases: 10s-60s+ linting time
• Multiple plugins compound slowness
• TypeScript rules particularly slow
• No built-in parallelization

Optimization Strategies:

• Enable caching (--cache)
• Limit plugin count
• Use flat config (ESLint 9+)
• Consider Biome for speed-critical projects

Comparison:

• Biome: 15x faster than ESLint
• ESLint with cache: Moderate improvement
• ESLint without cache: Baseline

Rule Coverage#

Built-in Categories:

Possible Errors:

• no-console: Disallow console statements
• no-debugger: Disallow debugger statements
• no-dupe-keys: Disallow duplicate object keys
• no-unreachable: Disallow unreachable code

Best Practices:

• eqeqeq: Require === and !==
• no-eval: Disallow eval()
• no-implied-eval: Disallow implied eval
• no-var: Require let/const instead of var

ES6+:

• prefer-const: Prefer const over let
• prefer-arrow-callback: Prefer arrow functions
• prefer-template: Prefer template literals
• no-useless-constructor: Disallow unnecessary constructors

Style (Discouraged - Use Prettier):

• indent, quotes, semi, etc.
• Better handled by formatters

Popular Plugins#

TypeScript:

• @typescript-eslint/eslint-plugin
• 100+ TypeScript-specific rules
• Type-aware rules (requires tsconfig.json)

React:

• eslint-plugin-react
• eslint-plugin-react-hooks
• JSX best practices, hook rules

Testing:

• eslint-plugin-jest
• eslint-plugin-testing-library
• Test-specific best practices

Accessibility:

• eslint-plugin-jsx-a11y
• ARIA rules, accessibility checks

Import/Module:

• eslint-plugin-import
• Import order, resolution, circular dependencies

Unicorn:

• eslint-plugin-unicorn
• Additional best practices

Configuration#

Configuration Files:

• eslint.config.js (ESLint 9+ flat config)
• .eslintrc.js / .eslintrc.json (legacy)
• .eslintrc.yml
• package.json ("eslintConfig" key)

Flat Config Example (ESLint 9+):

import js from '@eslint/js';
import typescript from '@typescript-eslint/eslint-plugin';
import react from 'eslint-plugin-react';
import prettier from 'eslint-config-prettier';

export default [
  js.configs.recommended,
  {
    files: ['**/*.ts', '**/*.tsx'],
    languageOptions: {
      parser: '@typescript-eslint/parser',
      parserOptions: {
        project: './tsconfig.json'
      }
    },
    plugins: {
      '@typescript-eslint': typescript,
      'react': react
    },
    rules: {
      '@typescript-eslint/no-unused-vars': 'error',
      'react/jsx-uses-react': 'off',
      'react/react-in-jsx-scope': 'off'
    }
  },
  prettier
];

Legacy Config Example:

{
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended",
    "plugin:react/recommended",
    "prettier"
  ],
  "parser": "@typescript-eslint/parser",
  "parserOptions": {
    "ecmaVersion": 2024,
    "sourceType": "module",
    "project": "./tsconfig.json"
  },
  "plugins": ["@typescript-eslint", "react"],
  "rules": {
    "@typescript-eslint/no-unused-vars": "error",
    "eqeqeq": ["error", "always"],
    "no-console": "warn"
  }
}

Prettier Integration#

Recommended Approach:

1. Install eslint-config-prettier:

   npm install --save-dev eslint-config-prettier

2. Add to config (must be last):

   {
     "extends": [
       "eslint:recommended",
       "prettier"
     ]
   }

3. Run separately:

   prettier --write . && eslint --fix .

Alternative (Not Recommended):

• eslint-plugin-prettier: Runs Prettier as ESLint rule
• Cons: Slower, conflates concerns
• Use only if you must have single command

IDE and Ecosystem Integration#

IDE Support (Excellent):

• VS Code: Official ESLint extension (10M+ installs)
• WebStorm/IntelliJ: Built-in support
• Vim/Neovim: coc-eslint, ALE
• Emacs: flycheck with eslint
• Sublime Text: SublimeLinter-eslint

VS Code Settings:

{
  "eslint.validate": [
    "javascript",
    "javascriptreact",
    "typescript",
    "typescriptreact"
  ],
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  }
}

CI/CD Integration:

• GitHub Actions: Multiple community actions
• Pre-commit: eslint hook
• Simple CLI for any CI system

Commands:

# Lint files
eslint .

# Auto-fix issues
eslint --fix .

# Check specific files
eslint src/**/*.ts

# Output JSON (for tooling)
eslint --format json .

Strengths#

Comprehensive Rule Coverage:

• 400+ built-in rules
• 1000+ community plugin rules
• Covers virtually all JS/TS patterns

Pluggable Architecture:

• Custom rules for company standards
• Framework-specific plugins
• Tool-specific plugins

Configurability:

• Per-project, per-directory, per-file configs
• Inline rule overrides (/* eslint-disable */)
• Granular severity levels (error, warn, off)

Maturity:

• 12+ years of development
• Battle-tested on millions of projects
• Extensive documentation
• Large community

TypeScript Support:

• Full TypeScript integration
• Type-aware rules
• Modern TS pattern enforcement

Limitations#

Performance:

• Single-threaded (slow on large codebases)
• Plugin overhead compounds
• 15x slower than Biome
• Caching helps but not enough for huge monorepos

Complexity:

• Configuration can be overwhelming
• Many overlapping rules
• Plugin conflicts possible
• Steep learning curve for custom rules

Formatting Rules:

• Style rules conflict with Prettier
• Formatting should be handled by Prettier/Biome
• eslint-config-prettier required

Breaking Changes:

• Major versions can have significant changes
• Plugin compatibility issues
• Migration effort (especially ESLint 9 flat config)

Use Cases#

Ideal For:

• Any JavaScript/TypeScript project (quality checks)
• Teams enforcing best practices
• Custom rule requirements
• Framework-specific linting (React, Vue, Angular)
• Large codebases with established ESLint configs

Less Ideal For:

• Projects needing only formatting (use Prettier/Biome)
• Performance-critical CI (consider Biome)
• Small scripts (overkill)

ESLint 9 Flat Config#

Major Change (2024-2025):

• New flat config format (.js based)
• Simpler, more explicit configuration
• Better TypeScript support
• Improved performance

Migration:

• Legacy configs still supported (for now)
• Migration tools available
• Documentation comprehensive

Recommended Workflows#

With Prettier (Separate):

# Format first
prettier --write .

# Then lint
eslint --fix .

Package.json Scripts:

{
  "scripts": {
    "format": "prettier --write .",
    "lint": "eslint --fix .",
    "quality": "npm run format && npm run lint"
  }
}

Pre-commit Hook:

repos:
  - repo: https://github.com/pre-commit/mirrors-prettier
    rev: v3.0.0
    hooks:
      - id: prettier
  - repo: https://github.com/pre-commit/mirrors-eslint
    rev: v9.0.0
    hooks:
      - id: eslint
        args: [--fix]

Comparison Summary#

vs. Biome Linter:

• ESLint: 1000+ rules, slow, mature
• Biome: 200+ rules, 15x faster, growing

vs. Prettier:

• ESLint: Linting/quality focus
• Prettier: Formatting focus only

vs. TSLint (Deprecated):

• ESLint: Active, with @typescript-eslint
• TSLint: Deprecated (migrated to ESLint)

Popular Shareable Configs#

Airbnb:

• eslint-config-airbnb
• Comprehensive, opinionated
• Most popular shareable config

Standard:

• eslint-config-standard
• Zero-config, JavaScript Standard Style

Google:

• eslint-config-google
• Google’s JavaScript style guide

XO:

• eslint-config-xo
• Opinionated, strict

Community and Maintenance#

Maturity: Very mature (12+ years) Activity: Active development GitHub Stars: ~25,000+ npm Downloads: ~60 million/month Maintainers: OpenJS Foundation

Ecosystem:

• 1000+ plugins
• Extensive Stack Overflow presence
• Active Discord/discussions
• Comprehensive documentation

Verdict#

ESLint remains the industry standard for JavaScript/TypeScript linting in 2025. Its comprehensive rule coverage, pluggable architecture, and mature ecosystem make it indispensable for code quality enforcement. While newer alternatives like Biome offer speed improvements, ESLint’s depth and breadth are unmatched.

Use ESLint if:

• You need comprehensive linting (quality, bugs, best practices)
• You have custom rule requirements
• You’re using framework-specific rules (React, Vue)
• Performance is acceptable for your codebase size

Consider alternatives if:

• You only need formatting (use Prettier/Biome instead)
• Performance is critical and rule coverage of Biome suffices
• You’re starting fresh and want unified tooling (Biome)

Recommended combination for 2025:

• Formatting: Prettier or Biome
• Linting: ESLint (with eslint-config-prettier)
• Best of both: Comprehensive checks + consistent formatting

ESLint’s role is clear: focus on what it does best (linting/quality), and let formatters handle style.

Code Formatter Feature Comparison Matrix#

Overview#

Comprehensive comparison of code formatting and linting tools across Python and JavaScript/TypeScript ecosystems. This matrix evaluates tools across performance, configuration, integration, and capability dimensions.

Quick Reference#

Performance Comparison#

Formatting Speed#

Python Formatters (250k lines codebase):

JavaScript Formatters (large codebase):

Linting Speed#

Python Linters:

JavaScript Linters:

Startup Time Impact#

Configuration Flexibility#

Philosophy Spectrum#

Configuration File Format#

Per-File Configuration#

IDE Integration#

VS Code Support#

PyCharm/WebStorm Support#

Vim/Neovim Support#

CI/CD Integration#

Pre-commit Hook Support#

GitHub Actions#

Docker/Container Friendliness#

Language and Feature Support#

Python Tools#

JavaScript/TypeScript Tools#

✓ = Full support, 🚧 = In progress, ✗ = Not supported

Compatibility and Migration#

Drop-in Replacement Compatibility#

Breaking Change Frequency#

Cross-Platform Consistency#

Advanced Features#

Incremental Formatting#

Multi-threading#

Plugin/Extension System#

Ecosystem Maturity#

Community Metrics (December 2025)#

Documentation Quality#

Decision Matrix#

Choose Based on Priority#

Priority: Speed (Large Codebase, CI Performance)

1. Ruff (Python)
2. Biome (JS/TS)
3. dprint (JS/TS multi-language)

Priority: Stability (Battle-tested, Mature)

1. Black (Python)
2. Prettier (JS/TS)
3. ESLint (JS/TS linting)

Priority: Unified Toolchain (Format + Lint)

1. Ruff (Python)
2. Biome (JS/TS)

Priority: Configuration Flexibility

1. ESLint (JS/TS linting)
2. YAPF (Python formatting)

Priority: Language Coverage (Multi-language projects)

1. Prettier (JS/TS/CSS/HTML/Markdown/YAML)
2. dprint (similar coverage, faster)

Priority: Linting Depth (Comprehensive checks)

1. ESLint (JS/TS)
2. Ruff (Python)

Summary Recommendations#

Python Projects#

• New project: Ruff (format + lint)
• Established project: Black + Ruff (lint)
• Maximum stability: Black + Flake8/isort
• Performance critical: Ruff

JavaScript/TypeScript Projects#

• New project: Biome (format + lint)
• Established project: Prettier + ESLint
• Large monorepo: Biome (performance)
• Multi-language: Prettier (coverage)
• Maximum linting: Prettier + ESLint

Hybrid Approach#

• Biome/Ruff for speed on JS/TS or Python
• Prettier for additional languages (HTML, Markdown, YAML)
• ESLint for comprehensive JS/TS linting if Biome insufficient

Performance Benchmarks: Code Formatters and Linters#

Overview#

This document provides detailed performance benchmarks for code formatting and linting tools across Python and JavaScript/TypeScript ecosystems. All benchmarks include methodology, hardware context, and practical implications for different project sizes.

Benchmark Methodology#

Test Conditions#

Hardware Baselines:

• Standard: Intel i7-12700 (12 cores), 32GB RAM, NVMe SSD
• High-end: Apple M1 Max (10 cores), 64GB RAM, NVMe SSD
• CI: GitHub Actions runners (2 cores, 7GB RAM)

Codebase Sizes:

• Small: 10,000 lines (~50 files)
• Medium: 100,000 lines (~500 files)
• Large: 250,000 lines (~1,200 files)
• Extra Large: 1,000,000 lines (~5,000 files)

Test Methodology:

• Cold start (no cache)
• Warm start (with cache where available)
• Average of 10 runs
• Exclude first run (JIT warmup)

Python Formatter Benchmarks#

Ruff vs. Black: The 30-100x Speedup#

Test Codebase: Zulip (~250,000 lines)

Interpretation:

• Ruff achieves <100ms formatting on 250k lines
• Even Black’s best case (cached) is 21x slower
• YAPF’s Python implementation shows GIL limitations

Small Codebase (10,000 lines)#

Single File vs. Project-wide:

Startup Time Impact:

• Ruff: Negligible (<10ms binary startup)
• Black: ~100-150ms (Python interpreter + imports)
• YAPF: ~200ms (heavier dependencies)

Large Codebase (1,000,000 lines)#

Monorepo Performance:

Pre-commit Hook Impact:

Scenario: Developer commits 5 changed files (~2,500 lines)

Real-World Case Studies#

Apache Airflow Migration (Black → Ruff):

• Codebase: ~450,000 lines
• Black time: 5.8s (cached), 9.2s (cold)
• Ruff time: 180ms
• Speedup: 32x (cached), 51x (cold)
• CI time saved: ~4 minutes per build

pandas Project:

• Codebase: ~380,000 lines
• Pre-commit hook time: 8s → 95ms
• Developer impact: Near-instant commits

Python Linter Benchmarks#

Ruff Check vs. Flake8#

Test Codebase: FastAPI (~50,000 lines)

Rule Coverage Comparison:

Import Sorting: Ruff vs. isort#

Test Codebase: Django (~2,772 files)

Speedup: 21x faster Compatibility: ~95% (6 file difference due to edge cases)

JavaScript/TypeScript Formatter Benchmarks#

Biome vs. Prettier: The 25x Speedup#

Test Codebase: React Monorepo (312 files, ~85,000 lines)

Apple M1 Max (10 cores) Performance:

Interpretation:

• Biome’s multi-threading scales with cores
• Single-threaded Biome still ~7x faster than Prettier
• dprint (Rust, highly optimized) fastest overall

Small Project (5,000 lines)#

Typical React App:

Large Monorepo (500,000 lines)#

Enterprise TypeScript Monorepo:

Pre-commit Hook (10 changed files):

Real-World Migrations#

Case Study 1: E-commerce Platform

• Codebase: 180,000 lines TypeScript + React
• Team size: 15 developers
• Before (Prettier): 18s format time, 45s total quality checks
• After (Biome): 2.1s format + lint combined
• Result: 10s → 80ms pre-commit hooks

Case Study 2: SaaS Dashboard

• Codebase: 65,000 lines
• Before (Prettier + ESLint): 8s pre-commit
• After (Biome): 350ms pre-commit
• Developer feedback: “Commits feel instant now”

JavaScript/TypeScript Linter Benchmarks#

Biome Lint vs. ESLint#

Test Codebase: Next.js App (~45,000 lines)

Plugin Impact on ESLint:

Combined Format + Lint Performance#

Unified Toolchains vs. Separate Tools#

Python (250k lines):

Speedup: Ruff unified is 53x faster than traditional stack

JavaScript/TypeScript (85k lines):

Speedup: Biome unified is 26x faster than separate tools

CI/CD Performance Impact#

GitHub Actions: Before and After#

Python Project (FastAPI-style API):

TypeScript Project (React SPA):

Monorepo CI Impact#

Large Python Monorepo (1M lines):

Memory Consumption#

RAM Usage During Formatting#

Large Codebase (500k lines):

Implication: Rust-based tools use ~50% less memory

Disk I/O Impact#

Cache Directory Sizes#

Scaling Characteristics#

Performance vs. Codebase Size#

Ruff Scaling (Python):

Interpretation: Ruff exhibits sub-linear scaling (better than O(n))

Biome Scaling (TypeScript, multi-threaded):

Interpretation: Multi-threading shows diminishing returns at scale (Amdahl’s law)

Network/Download Impact#

Package Installation Size#

Implication: Rust binaries significantly faster in CI setup

Practical Decision Framework#

When Speed Matters#

High Priority (choose fast tools):

• Large monorepos (>100k lines)
• Frequent commits (>50/day/team)
• Pre-commit hooks (developer experience)
• CI/CD pipelines (cost + feedback speed)
• Watch mode / save-on-format

Medium Priority (balance speed and maturity):

• Medium projects (10k-100k lines)
• Moderate commit frequency
• Established teams with existing configs

Low Priority (stability over speed):

• Small projects (<10k lines)
• Infrequent commits
• Conservative organizations
• Legacy codebases with complex custom rules

Summary: Performance Champions#

Python#

• Fastest Formatter: Ruff (30-100x faster than Black)
• Fastest Linter: Ruff (10-100x faster than Flake8)
• Fastest Import Sort: Ruff (21x faster than isort)
• Best Unified: Ruff (format + lint + import sort)

JavaScript/TypeScript#

• Fastest Formatter: dprint (100x faster than Prettier)
• Fastest Practical Formatter: Biome (25x faster, better features)
• Fastest Linter: Biome (15x faster than ESLint)
• Best Unified: Biome (format + lint + import org)

Real-World Impact#

Time Saved Annually (100 developers, 1M line codebase):

Traditional Stack (Black + Flake8 + isort):

• Per check: 14s
• Checks per developer per day: 30
• Total daily: 11.7 hours
• Annual cost: 3,000 hours (1.5 FTE)

Modern Stack (Ruff):

• Per check: 265ms
• Checks per developer per day: 30
• Total daily: 13.25 minutes
• Annual cost: 57 hours (0.03 FTE)

Savings: 2,943 hours/year or $147,150/year (at $50/hour)

Similar calculations apply for JavaScript/TypeScript projects using Biome vs. Prettier + ESLint.

Conclusion#

Performance differences between traditional Python/JavaScript tools and modern Rust-based alternatives are not marginal—they are transformative:

• 30-100x speedups fundamentally change developer experience
• Sub-second quality checks enable instant feedback loops
• Reduced CI costs through faster pipelines
• Unified toolchains eliminate configuration complexity while improving speed

For new projects or teams with performance-critical workflows, modern tools (Ruff, Biome) are clear winners. For established projects, migration effort is minimal with substantial long-term gains.

Prettier: Opinionated Code Formatter for JavaScript and More#

Overview#

Prettier is the most popular code formatter for JavaScript, TypeScript, and web technologies. Released in 2017, it pioneered the “opinionated formatter” concept in the JavaScript ecosystem, eliminating style debates through deliberate lack of configuration.

Current Status: Mature, industry standard Written In: JavaScript License: MIT First Release: 2017 Latest Version: 3.x (as of December 2025) Monthly Downloads: ~50 million (npm)

Core Philosophy#

Prettier follows the principle: “You press save and code is formatted. No discussion needed.”

Design Principles:

• Opinionated with minimal configuration
• Multi-language support (JS, TS, CSS, HTML, JSON, Markdown, YAML, etc.)
• Focus on consistent output over customization
• Print width optimization (line length management)
• AST-based formatting (safe, semantic-preserving)

The Prettier Style:

• Single quotes (configurable)
• Semicolons (configurable)
• 2-space indentation (configurable)
• 80 character print width (configurable)
• Trailing commas in multi-line structures

Language Support#

First-Class Support:

• JavaScript (ES5-ES2024+)
• TypeScript
• JSX/TSX (React)
• CSS, SCSS, Less
• JSON
• HTML
• Markdown
• YAML
• GraphQL

Plugin Support:

• PHP (via plugin)
• Ruby (via plugin)
• Java (via plugin)
• Python (via plugin - limited)
• XML (via plugin)
• Many others

Performance Characteristics#

Speed Benchmarks:

• ~1,000-2,000 files: 2-3 seconds (single-threaded)
• Baseline for JavaScript formatter comparisons
• Adequate for most projects, but not optimized for large monorepos

Performance Limitations:

• Single-threaded (no parallel processing)
• JavaScript-based (V8 performance ceiling)
• Startup overhead on small files
• No incremental formatting (formats entire files)

Caching:

• --cache flag available (v2.0+)
• Caches formatting results
• Significantly speeds up repeated runs
• Useful in CI pipelines

Configuration#

Prettier deliberately limits configuration options to prevent style debates:

Available Options:

• printWidth (default 80)
• tabWidth (default 2)
• useTabs (default false)
• semi (default true)
• singleQuote (default false)
• quoteProps (as-needed, consistent, preserve)
• trailingComma (es5, none, all)
• bracketSpacing (default true)
• arrowParens (always, avoid)
• endOfLine (lf, crlf, cr, auto)

Configuration Files:

• .prettierrc (JSON, YAML, or JS)
• .prettierrc.json, .prettierrc.yml, .prettierrc.js
• prettier.config.js
• package.json ("prettier" key)

Example Configuration:

{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "trailingComma": "es5",
  "bracketSpacing": true,
  "arrowParens": "avoid"
}

IDE and Ecosystem Integration#

IDE Support (Excellent):

• VS Code: Official extension (10M+ installs)
• WebStorm/IntelliJ: Built-in support
• Vim/Neovim: Multiple plugins (vim-prettier, coc-prettier)
• Emacs: prettier-emacs
• Sublime Text: JsPrettier plugin

Build Tool Integration:

• webpack: prettier-webpack-plugin
• ESLint: eslint-plugin-prettier
• lint-staged: Direct integration
• Husky: Pre-commit hook support

CI/CD Integration:

• GitHub Actions: Multiple community actions
• Pre-commit: prettier hook
• GitLab CI, CircleCI: Simple command execution

Editor Plugins:

• Format on save
• Format selection
• Format on paste
• Real-time feedback

Compatibility and Integration#

ESLint Integration:

Two approaches:

1. eslint-plugin-prettier (Run Prettier as ESLint rule)

   {
     "extends": ["plugin:prettier/recommended"]
   }

   Pros: Single command Cons: Slower, conflates formatting and linting

2. Separate tools (Recommended)

   prettier --write . && eslint --fix .

   Pros: Clear separation, faster Cons: Two commands

eslint-config-prettier: Disables ESLint rules that conflict with Prettier:

{
  "extends": ["eslint:recommended", "prettier"]
}

Strengths#

Consistency:

• Eliminates style debates
• Same output across team members
• Stable output across versions

Multi-Language:

• Single tool for JS, TS, CSS, HTML, JSON, Markdown
• Consistent formatting across entire project
• Reduces tool complexity

Adoption:

• Industry standard (highest npm downloads)
• Universal IDE support
• Extensive documentation
• Large community

Ease of Use:

• Zero-config getting started
• Intuitive options
• Easy to understand output

Safety:

• AST-based (never breaks code)
• Extensive test suite
• Semantic preservation guarantees

Limitations#

Performance:

• 7-25x slower than Biome
• 10-100x slower than dprint
• Single-threaded (no parallelization)
• Noticeable in large monorepos

Configurability:

• Limited options (by design)
• Cannot adapt to many existing style guides
• No per-file overrides (only ignore files)

Linting:

• Only formats, doesn’t lint
• Requires separate ESLint setup
• Two tools = two configs, two runs

ESLint Conflicts:

• Requires eslint-config-prettier to avoid conflicts
• Plugin approach (eslint-plugin-prettier) slower
• Integration complexity

Use Cases#

Ideal For:

• Web development projects (JS/TS/React/Vue)
• Teams wanting zero-config formatting
• Multi-language codebases (JS + CSS + HTML + Markdown)
• Projects prioritizing consistency over customization
• Organizations standardizing across multiple projects

Less Ideal For:

• Large monorepos (performance issues)
• Teams with strict existing style guides
• Projects requiring deep customization
• Performance-critical CI pipelines

Comparison Context#

vs. Biome:

• Prettier: Mature, multi-language, slower
• Biome: 25x faster, JS/TS/JSON only, 97% compatible

vs. dprint:

• Prettier: More languages, slower, larger ecosystem
• dprint: 10-100x faster, plugin-based, less adoption

vs. ESLint:

• Prettier: Formatting only, opinionated
• ESLint: Linting focus, highly configurable

Recommended Workflows#

Standard Setup:

# Install
npm install --save-dev prettier

# Create config
echo '{"singleQuote": true, "printWidth": 100}' > .prettierrc.json

# Format
npx prettier --write .

With ESLint (Separate):

# Format first
npx prettier --write .

# Then lint
npx eslint --fix .

Pre-commit Hook:

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,ts,jsx,tsx,css,md,json}": ["prettier --write"]
  }
}

VS Code Settings:

{
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": true
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode",
    "editor.formatOnSave": true
  },
  "[json]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

package.json scripts:

{
  "scripts": {
    "format": "prettier --write .",
    "format:check": "prettier --check .",
    "lint": "eslint --fix .",
    "quality": "npm run format && npm run lint"
  }
}

Community and Maintenance#

Maturity: Very mature (8+ years) Activity: Active development, stable GitHub Stars: ~49,000+ npm Downloads: ~50 million/month Maintainers: Community-driven (Prettier organization)

Ecosystem:

• 100+ editor plugins
• Extensive Stack Overflow presence
• Active Discord community
• Comprehensive documentation

Migration Considerations#

From Manual Formatting:

• Expect significant initial diff
• Recommend separate “format all” commit
• Use .prettierignore for legacy code

From ESLint Formatting Rules:

• Disable conflicting ESLint rules (eslint-config-prettier)
• Run Prettier first, then ESLint
• Update CI pipelines

To Biome:

• Biome provides ~97% compatibility
• Migration command: npx biome migrate prettier --write
• Review differences before committing

Prettier 3.x Updates#

Major Changes (v3.0+):

• Improved TypeScript support
• Better JSX formatting
• Enhanced performance (still slower than Biome/dprint)
• Simplified plugin API

Verdict#

Prettier remains the gold standard for JavaScript/TypeScript formatting in 2025. Its opinionated approach and multi-language support have made it indispensable for web development. While newer alternatives like Biome offer significant speed improvements, Prettier’s maturity, ecosystem, and language coverage make it a reliable default choice.

Choose Prettier if: You want the battle-tested industry standard with maximum language coverage and ecosystem support.

Consider alternatives if: Performance is critical (large monorepo) or you want unified formatting + linting (Biome).

Recommended combination: Prettier (formatting) + ESLint (linting) remains a proven, robust setup for most JavaScript/TypeScript projects in 2025.

Code Formatting Tool Recommendations: Evidence-Based Selection Guide#

Overview#

This guide provides evidence-based recommendations for selecting code formatting and linting tools based on project characteristics, team priorities, and ecosystem constraints. Recommendations synthesize performance benchmarks, feature comparisons, and real-world migration experiences.

Quick Decision Matrix#

Python Projects#

JavaScript/TypeScript Projects#

Detailed Recommendations#

Python: The Ruff vs. Black Decision#

Choose Ruff Format + Ruff Check (Unified) If:#

Performance is a priority:

• Large codebase (>100k lines)
• Frequent commits (>50/day/team)
• Slow CI pipelines (quality checks >30s)
• Pre-commit hooks feel sluggish

Simplicity is valued:

• New project without legacy constraints
• Desire to reduce tool count (5 tools → 1)
• Team wants unified configuration
• Simplified dependency management

Modern tooling preferred:

• Team comfortable with newer tools
• Willing to adopt actively developed projects
• Value Rust-based performance

Migration effort acceptable:

• Expected impact: <0.1% line changes from Black
• Compatible with >99.9% of Black output
• Easy rollback if needed

Practical Example:

# pyproject.toml - Single unified config
[tool.ruff]
line-length = 88
target-version = "py311"

[tool.ruff.lint]
select = ["E", "F", "I", "UP", "B", "C4"]
ignore = ["E501"]  # Line length handled by formatter

[tool.ruff.format]
quote-style = "double"

Commands:

# Format and lint in one go
ruff check --fix . && ruff format .

# Or use pre-commit
ruff check --fix . ; ruff format .

Choose Black + Ruff Check (Hybrid) If:#

Stability is paramount:

• Conservative organization
• Risk-averse team culture
• Prefer 7+ year battle-tested tools
• Existing Black formatting satisfactory

100% Black compatibility required:

• Zero tolerance for formatting differences
• Large existing codebase reviewed and approved
• Legal/compliance requirements for minimal changes

Gradual migration preferred:

• Phase 1: Keep Black, add Ruff linter
• Phase 2: Evaluate Ruff formatter on branches
• Phase 3: Switch after team approval

Practical Example:

# pyproject.toml - Hybrid approach
[tool.black]
line-length = 88
target-version = ['py311']

[tool.ruff]
line-length = 88

[tool.ruff.lint]
select = ["E", "F", "I", "UP", "B"]
# Exclude formatting rules (Black handles those)
ignore = ["E501"]

Commands:

# Format with Black
black .

# Lint with Ruff
ruff check --fix .

Avoid Black + Flake8 + isort (Traditional Stack) Unless:#

Specific plugins required:

• Custom Flake8 plugins not in Ruff
• Company-specific linting rules

Team resistance to change:

• Team familiar with existing tools
• No performance pain points
• “If it ain’t broke, don’t fix it” culture

Note: This stack is 53x slower than unified Ruff. Strongly consider migration.

JavaScript/TypeScript: The Biome vs. Prettier Decision#

Choose Biome (Format + Lint) If:#

Performance is critical:

• Large monorepo (>100k lines)
• Slow pre-commit hooks (>2s)
• CI pipelines taking minutes for quality checks
• Many developers committing frequently

Unified tooling desired:

• Prefer single tool over Prettier + ESLint
• Simplified configuration
• Faster onboarding for new developers

Primary languages are JS/TS:

• Project is >90% JavaScript/TypeScript/JSON/CSS
• Don’t need HTML/YAML/Markdown formatting
• Can use Prettier for auxiliary files if needed

ESLint rule coverage sufficient:

• Biome’s ~200 rules cover your needs
• No custom ESLint plugins required
• Standard React/TypeScript project

Migration acceptable:

• ~97% Prettier compatibility
• Migration tools available
• Team willing to review differences

Practical Example:

// biome.json - Unified config
{
  "$schema": "https://biomejs.dev/schemas/1.9.4/schema.json",
  "organizeImports": {
    "enabled": true
  },
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  },
  "formatter": {
    "enabled": true,
    "indentStyle": "space",
    "indentWidth": 2,
    "lineWidth": 100
  },
  "javascript": {
    "formatter": {
      "quoteStyle": "single",
      "trailingCommas": "es5"
    }
  }
}

Commands:

# Format and lint together
biome check --write .

# CI check (no modifications)
biome ci .

Choose Prettier + ESLint (Separate) If:#

Multi-language project:

• Need HTML, YAML, Markdown formatting
• Using Vue, Svelte with templates
• GraphQL queries need formatting

Maximum ESLint ecosystem needed:

• Custom company/team ESLint plugins
• Framework-specific rules (Angular, Ember)
• Specific third-party plugins essential

Stability over speed:

• Team prefers 8-year battle-tested tools
• Performance adequate for project size
• Risk-averse organization

Complex ESLint configurations:

• Dynamic JavaScript configs (environment-based)
• Per-file overrides extensively used
• Cannot convert to JSON-based config

Practical Example:

// .prettierrc
{
  "printWidth": 100,
  "singleQuote": true,
  "trailingComma": "es5"
}

// eslint.config.js (ESLint 9 flat config)
import js from '@eslint/js';
import typescript from '@typescript-eslint/eslint-plugin';
import prettier from 'eslint-config-prettier';

export default [
  js.configs.recommended,
  {
    files: ['**/*.ts', '**/*.tsx'],
    plugins: { '@typescript-eslint': typescript },
    rules: {
      '@typescript-eslint/no-unused-vars': 'error'
    }
  },
  prettier // Disable conflicting rules
];

Commands:

# Format first, then lint
prettier --write . && eslint --fix .

Hybrid Approach: Biome + Prettier If:#

Best of both worlds:

• Use Biome for JS/TS formatting + linting (fast)
• Use Prettier for HTML/Markdown/YAML (coverage)
• Separate concerns cleanly

Practical Example:

// package.json scripts
{
  "scripts": {
    "format:js": "biome format --write .",
    "format:other": "prettier --write '**/*.{html,md,yml}'",
    "format": "npm run format:js && npm run format:other",
    "lint": "biome lint --write ."
  }
}

Migration Strategies#

Python: Black → Ruff Format#

Phase 1: Assessment (1-2 hours)

1. Run Ruff on codebase to see differences:

   ruff format --diff . | wc -l

2. Review changes (expect <0.1% lines affected)
3. Identify any problematic differences

Phase 2: Parallel Testing (1 week)

1. Add Ruff to CI alongside Black (don’t block)
2. Monitor differences on new PRs
3. Gather team feedback

Phase 3: Migration (1 day)

1. Create migration branch
2. Run Ruff format:

   ruff format .

3. Commit with message: “Migrate to Ruff formatter (Black-compatible)”
4. Update CI/pre-commit configs
5. Remove Black dependency

Phase 4: Rollback Plan Keep Black config for 1-2 sprints:

# If issues arise, revert:
git revert <ruff-commit>
black .

Expected Impact:

• Time: 2-4 hours total effort
• Code changes: <0.1% of lines
• Performance gain: 30-100x faster formatting

JavaScript: Prettier + ESLint → Biome#

Phase 1: Assessment (2-3 hours)

1. Use Biome migration tools:

   npx @biomejs/biome migrate prettier --write
   npx @biomejs/biome migrate eslint --write

2. Review generated biome.json
3. Test formatting differences:

   biome format --write .
   git diff --stat

4. Identify ESLint rules not covered by Biome

Phase 2: Gradual Adoption (2-4 weeks)

1. Use Biome on new modules/features
2. Keep Prettier + ESLint on existing code
3. Compare performance and ergonomics

Phase 3: Full Migration (1-2 days)

1. Run Biome across entire codebase
2. Address unmapped ESLint rules:
   • Accept Biome equivalents
   • Or keep ESLint for specific rules
3. Update CI/pre-commit configs
4. Remove Prettier, potentially keep ESLint

Phase 4: Hybrid (if needed) If some ESLint rules essential:

{
  "scripts": {
    "format": "biome format --write .",
    "lint": "biome lint --write . && eslint --fix ."
  }
}

Expected Impact:

• Time: 1-2 days total effort
• Code changes: ~3% of lines (mostly minor)
• Performance gain: 25x faster formatting, 15x faster linting

Team Size Considerations#

Small Team (1-5 developers)#

Python:

• Recommended: Ruff (format + lint)
• Rationale: Simplicity, minimal config, fast

JavaScript:

• Recommended: Biome or Prettier + ESLint
• Rationale: Either works, choose based on multi-language needs

Priority: Developer experience, simplicity

Medium Team (5-20 developers)#

Python:

• Recommended: Ruff (format + lint) or Black + Ruff lint
• Rationale: Performance starts mattering, unified tooling helps onboarding

JavaScript:

• Recommended: Biome (fast) or Prettier + ESLint (stable)
• Rationale: Pre-commit hooks noticeable, choose based on stability vs. speed

Priority: Balance performance and stability

Large Team (20+ developers)#

Python:

• Strongly recommended: Ruff (format + lint)
• Rationale: Performance critical, CI costs add up, unified reduces confusion

JavaScript:

• Strongly recommended: Biome
• Rationale: 25x speedup × many developers = major productivity gain

Priority: Performance, CI cost reduction, consistency

Codebase Size Considerations#

Small (<10k lines)#

Python: Black or Ruff (either fine) JavaScript: Prettier or Biome (either fine) Rationale: Performance differences imperceptible

Medium (10k-100k lines)#

Python: Ruff preferred (noticeable speed gain) JavaScript: Biome preferred (pre-commit hooks faster) Rationale: Performance improvements felt by developers

Large (100k-500k lines)#

Python: Ruff strongly recommended (30x faster) JavaScript: Biome strongly recommended (25x faster) Rationale: Traditional tools become painfully slow

Extra Large (>500k lines)#

Python: Ruff essential (traditional tools impractical) JavaScript: Biome essential (Prettier takes minutes) Rationale: Performance differences are transformative

Industry and Domain Considerations#

Startups and Fast-Moving Teams#

Recommendation: Modern, fast tools (Ruff, Biome) Rationale:

• Speed to market prioritized
• Less legacy constraint
• Developer productivity critical
• Willing to adopt new tools

Enterprise and Regulated Industries#

Recommendation: Stable, battle-tested tools (Black, Prettier + ESLint) Rationale:

• Risk aversion
• Compliance requirements
• Change management overhead
• Extensive existing codebases

Alternative: Ruff/Biome with extended evaluation period

Open Source Projects#

Python:

• Recommendation: Ruff (if started recently) or Black (established standard)
• Rationale: Community familiarity, easy contributor setup

JavaScript:

• Recommendation: Prettier + ESLint (universal recognition)
• Rationale: Maximum contributor compatibility

Consulting/Agencies (Multi-Client)#

Recommendation: Flexible, client-matching tools Python: Maintain both Black and Ruff capabilities JavaScript: Maintain both Prettier+ESLint and Biome Rationale: Adapt to client preferences, demonstrate modern options

Continuous Integration Considerations#

CI Performance Critical (High Commit Frequency)#

Python: Ruff (53x faster than traditional stack) JavaScript: Biome (26x faster than Prettier + ESLint) Rationale: Multiply per-check time × commits/day × cost/minute

CI Performance Acceptable#

Python: Black + Ruff lint or Ruff JavaScript: Prettier + ESLint or Biome Rationale: Flexibility to choose based on other factors

Cost-Optimized CI#

Python: Ruff (fewer dependencies, faster setup) JavaScript: Biome (fewer dependencies, faster setup) Rationale: Reduce runner time, dependency installation time

Special Scenarios#

Jupyter Notebook Formatting#

Recommendation: Ruff or Black (both support notebooks) Tools:

• Ruff: Built-in support via ruff format
• Black: Via black-jupyter or nbqa

Monorepos with Multiple Languages#

Recommendation: Language-specific tools Python + JavaScript:

• Use Ruff for Python
• Use Biome for JavaScript
• Use Prettier for shared formats (Markdown, YAML)

Alternative: Single tool where overlap

• Prettier for JS + JSON + Markdown + YAML
• Ruff for Python only

CI/CD Pipelines (Quality Gates)#

Recommendation:

• Use --check modes (no modifications)
• Fail builds on formatting violations
• Separate formatting check from linting

Python:

ruff format --check .
ruff check .

JavaScript:

biome ci .
# or
prettier --check . && eslint .

Pre-commit Hooks (Developer Experience)#

Priority: Speed above all Python: Ruff (instant feedback) JavaScript: Biome or dprint (instant feedback)

Avoid: Slow tools in pre-commit (frustrates developers)

Technology Stack Integration#

Django Projects#

Recommendation: Ruff (format + lint) Specific Config:

[tool.ruff.lint]
select = ["E", "F", "I", "DJ"]  # DJ = Django-specific rules

FastAPI Projects#

Recommendation: Ruff (format + lint) Rationale: FastAPI itself uses Ruff

React Projects#

Recommendation: Biome (format + lint) Specific Config:

{
  "linter": {
    "rules": {
      "recommended": true,
      "a11y": {
        "recommended": true
      }
    }
  }
}

Next.js Projects#

Recommendation: Prettier + ESLint (Next.js bundles ESLint config) Alternative: Biome (faster, but requires manual Next.js rule mapping)

TypeScript Strict Projects#

Recommendation: Prettier + @typescript-eslint (comprehensive rules) Alternative: Biome (faster, growing type-aware rules)

Decision Tree Summary#

Python Decision Tree#

Start
├─ New project?
│  └─ YES → Ruff (format + lint)
├─ Large codebase (>100k lines)?
│  └─ YES → Ruff (performance critical)
├─ Conservative organization?
│  └─ YES → Black + Ruff lint
├─ Custom style guide needed?
│  └─ YES → YAPF + Ruff lint
└─ Default → Ruff (format + lint)

JavaScript Decision Tree#

Start
├─ New project AND JS/TS only?
│  └─ YES → Biome
├─ Multi-language (HTML/YAML/Markdown)?
│  └─ YES → Prettier + ESLint
├─ Large monorepo (>100k lines)?
│  └─ YES → Biome (performance)
├─ Custom ESLint plugins required?
│  └─ YES → Prettier + ESLint
└─ Default → Biome OR Prettier + ESLint

Final Recommendations#

2025 Default Stack#

Python:

• Formatting: Ruff
• Linting: Ruff
• Import Sorting: Ruff
• Why: Unified, 30-100x faster, battle-tested by major projects

JavaScript/TypeScript:

• Formatting: Biome OR Prettier
• Linting: Biome OR ESLint
• Why: Biome for speed (new projects), Prettier + ESLint for stability

Conservative Stack (Maximum Stability)#

Python:

• Formatting: Black
• Linting: Ruff (or Flake8 if needed)
• Import Sorting: Ruff (or isort)

JavaScript/TypeScript:

• Formatting: Prettier
• Linting: ESLint

Performance-Optimized Stack (Large Codebases)#

Python: Ruff (everything) JavaScript: Biome (everything)

Conclusion#

The code formatting landscape in 2025 is defined by a clear trend: Rust-based, unified toolchains (Ruff, Biome) offer transformative performance improvements (30-100x) while maintaining compatibility with established standards (Black, Prettier).

Key Takeaway:

• New projects: Use modern tools (Ruff, Biome)
• Existing projects: Migrate if performance matters
• Conservative teams: Hybrid approaches work well (Black + Ruff lint)
• No wrong choice: All tools in this analysis are production-ready

The shift is clear: By 2025, Ruff has become the default for Python, and Biome is rapidly becoming the default for JavaScript/TypeScript. However, Black and Prettier remain excellent choices for stability-focused teams.

Choose based on your priorities: speed vs. stability, unified vs. specialized, modern vs. proven.

Ruff: Unified Python Linting and Formatting#

Overview#

Ruff is an extremely fast Python linter and code formatter written in Rust. It provides a unified toolchain combining linting (Flake8, pylint, pyupgrade, etc.) and formatting (Black-compatible) in a single tool, delivering 10-100x performance improvements over traditional Python tools.

Current Status: Rapidly maturing, production-ready Written In: Rust License: MIT First Release: 2022 Latest Version: 0.8.x (as of December 2025) Company: Astral (formerly maintained by Charlie Marsh)

Core Philosophy#

Ruff’s philosophy centers on unified toolchain performance: consolidate multiple Python quality tools (formatter, linter, import sorter) into a single, blazingly fast executable.

Design Principles:

• Extreme performance through Rust implementation
• Black-compatible formatting (>99.9% compatibility)
• isort-compatible import sorting
• Replace Flake8, Black, isort, pyupgrade, autoflake, and more
• Single configuration file
• Zero-downtime migration from existing tools

Architecture#

Two Primary Modes:

1. ruff check - Linting and auto-fixing

   • 800+ rules covering Flake8, pylint, pyupgrade, etc.
   • Import sorting (isort replacement)
   • Code quality checks
   • Auto-fixes for many rules

2. ruff format - Code formatting

   • Black-compatible formatter
   • AST-based, safe transformations
   • Does NOT currently sort imports (use ruff check --select I --fix)

Performance Characteristics#

Speed Benchmarks:

Formatter (ruff format):

• 30x faster than Black
• 100x faster than YAPF
• ~250,000 lines: <100ms (vs. Black’s 1-3 seconds)
• Even without caching, faster than Black with caching

Linter (ruff check):

• 10-100x faster than Flake8
• 98% faster in real-world cases (120ms vs 7s)
• Pre-commit hooks: 10s → 80ms in monorepo examples

Example Benchmarks (250k line codebase):

Why So Fast:

• Written in Rust (no GIL, true parallelization)
• Single binary (no Python startup time)
• Optimized parser and AST representation
• Minimal file I/O through shared infrastructure

Formatter: Black Compatibility#

Compatibility Level:

• >99.9% compatible with Black on Black-formatted code
• Django codebase: differ on 34 out of 2,772 files
• Zulip codebase: >99.9% identical output

Known Differences:

• Rare edge cases in string concatenation
• Subtle differences in comment placement
• Minimal impact on most codebases

Configuration Parity:

• Supports Black’s main options: line-length, target-version
• format.quote-style for string quotes
• format.indent-style (spaces/tabs)
• format.skip-magic-trailing-comma

Linter: Rule Coverage#

Built-in Rule Categories (800+ rules):

• Pyflakes (F): Logical errors
• pycodestyle (E, W): PEP 8 violations
• isort (I): Import sorting
• pydocstyle (D): Docstring conventions
• pyupgrade (UP): Modern Python syntax
• flake8-bugbear (B): Bug detection
• flake8-comprehensions (C4): List/dict comprehension improvements
• pylint (PL): Code quality checks
• Many more: 50+ Flake8 plugins implemented