Complete ESLint + Prettier Setup Guide

Teams often say they use ESLint and Prettier together, yet still waste review time on style noise, fight rule conflicts, or get different results locally and in CI. The problem is rarely the tools themselves. It is that teams have not decided clearly what each tool owns.

The strongest setup starts by separating mechanical formatting from semantic quality checks.

ESLint and Prettier Solve Different Problems

Prettier is best at formatting decisions humans should stop debating:

• quote style
• spacing
• line wrapping
• trailing commas

ESLint is better for:

• bug-prone patterns
• unused variables
• suspicious async mistakes
• unsafe framework or language usage

When teams blur these responsibilities, they create friction. When they separate them, code review gets quieter and more useful.

The Real Goal Is Team Predictability

A good setup should make these things true:

• files look the same regardless of who saved them
• local autofix is fast and boring
• CI enforces the same standards
• exceptions are explicit instead of tribal knowledge

This is less about tool fashion and more about turning style and safety into predictable defaults.

Keep the Base Rule Set Smaller Than People Expect

Many repositories import large recommended stacks and then spend months fighting the fallout. More rules do not automatically mean better quality.

A healthier pattern is:

• use Prettier for style
• keep ESLint focused on correctness and maintainability
• add framework-specific rules only when they solve recurring problems
• review noisy rules ruthlessly

Example:

{
  "extends": ["eslint:recommended", "plugin:@typescript-eslint/recommended", "prettier"]
}

The best rules are the ones the team will keep respecting six months later.

Local Autofix and CI Enforcement Should Not Have the Same Budget

Local workflows should optimize for speed. CI should optimize for trust.

Practical split:

• local save or pre-commit: formatting and lightweight fixes
• PR CI: full lint, typecheck, and other quality gates

If the local path is too heavy, developers bypass it. If CI is too weak, quality drifts quietly.

Monorepos Need Explicit Rule Ownership

In larger repositories, one global config is rarely enough by itself. Teams often need:

• a shared base config
• package-level overrides only where justified
• a clear owner for lint rule changes
• consistent handling for generated files and test utilities

Without ownership, lint configuration becomes a negotiation arena where exceptions accumulate faster than standards.

Common Failure Modes

• formatting and linting are allowed to fight each other
• local tool versions drift from CI versions
• teams import huge rule packs they do not understand
• pre-commit hooks become so slow that developers skip them
• warnings pile up until no one treats them as signals

A setup is only healthy if the team actually trusts and follows it.

Team Checklist

1. Is formatting clearly owned by Prettier and quality rules by ESLint?
2. Are local and CI results aligned through pinned versions and shared config?
3. Is the rule set small enough to stay explainable?
4. Are autofix and enforcement placed in the right layers?
5. Do lint warnings still mean something operationally?

Closing Judgment

ESLint and Prettier are effective not when they are maximally configured, but when their responsibilities are sharply separated and operated consistently. The real success metric is lower review noise and fewer avoidable mistakes, not a bigger rule file.

Continue Reading

Related posts

🔧 Tools

Webpack to Vite Migration Guide

A practical migration guide from Webpack to Vite focused on dev-server model changes, plugin inventory, environment handling, and production validation.

🔧 Tools

Designing Search Architecture for Engineering Docs

As documentation grows, the problem shifts from writing to finding. This guide explains how to design search-friendly engineering documentation.

💬 Language

TypeScript Utility Types: A Practical Guide

A production-focused guide to TypeScript utility types. Learn how to model DTOs, update payloads, selectors, and derived types without making your type layer harder to read.

💬 Language

TypeScript Generics: A Practical Guide

A practical and production-focused guide to TypeScript generics. Learn when generics improve API contracts, when they overcomplicate code, and how to keep inference readable.