ESLint vs Prettier Configuration Guide: Stop the Formatting Wars

I have spent way too many hours of my career in ‘formatting wars’—those endless PR comments arguing over whether a trailing comma should exist or if a function should have a space before the parentheses. For a long time, I thought I had to choose between ESLint and Prettier. Then I realized they aren’t competitors; they are teammates with very different jobs.

If you are looking for a definitive eslint vs prettier configuration guide, you’ve come to the right place. In this guide, I’ll break down why you need both, how to stop them from fighting, and how to automate the whole process so you never have to think about a semicolon again.

The Fundamentals: Linting vs. Formatting

Before we dive into the config files, we need to establish a mental model. The confusion usually stems from the fact that ESLint can do formatting, and Prettier only does formatting.

What is ESLint? (The Judge)

ESLint is a linter. Its primary goal is code quality. It analyzes your code to find problematic patterns that could lead to bugs. For example, ESLint will scream at you if you have an unused variable or if you’re trying to use a variable before it’s defined. It cares about the logic of your code.

What is Prettier? (The Stylist)

Prettier is an opinionated code formatter. It doesn’t care if your code is logically sound; it only cares that it looks consistent. It takes your code, strips away all existing styling, and reprints it according to its own strict rules. It cares about the visuals of your code.

In my experience, the magic happens when you let Prettier handle the aesthetics and let ESLint handle the architecture. When you try to make ESLint handle both, you end up with a configuration file that is 500 lines long and a team that is constantly frustrated by contradictory rules.

Deep Dive: The Conflict and the Cure

The Conflict: Why They Fight

The conflict occurs when ESLint has a rule that says “use single quotes” but Prettier is configured to “use double quotes.” When you save your file, Prettier changes it to double, and then ESLint immediately flags it as an error. It’s a loop of frustration.

The Solution: eslint-config-prettier

The industry standard for solving this is eslint-config-prettier. This is a config that turns off all ESLint rules that are unnecessary or might conflict with Prettier. Essentially, it tells ESLint: “Stop worrying about the spacing and quotes; Prettier has this covered.”

As shown in the image below, the goal is to create a clear separation of concerns where the formatter runs first, and the linter only reports on actual logic errors.

Comparison of code before and after Prettier formatting showing a messy JS file becoming clean and consistent

Implementation Step-by-Step

Here is how I set up my projects today. I’ll assume you have a Node.js project initialized.

1. Install the dependencies:

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

2. Configure Prettier:
Create a .prettierrc file in your root directory. I prefer keeping this minimal so Prettier can do its thing.


{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "es5"
}

3. Configure ESLint:
In your .eslintrc.json (or the newer eslint.config.js), add "prettier" as the last item in your extends array. This ensures it overrides any previous configurations.


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

Principles of a Clean Pipeline

Setting up the files is only half the battle. To truly eliminate the friction, you need to move these checks out of the developer’s conscious mind and into the automation pipeline.

Format on Save: Configure your IDE (like VS Code) to “Format on Save” using Prettier. This provides instant gratification and prevents dirty code from ever reaching the git stage.
Git Hooks: Don’t trust your teammates (including yourself) to run the linter. I highly recommend learning how to use husky for git hooks to run Prettier and ESLint on every commit.
CI Integration: Use automated code review tools for github to block PRs that don’t pass the linting check. This ensures the main branch remains pristine.

Common Pitfalls to Avoid

Over the years, I’ve seen a few recurring mistakes. Avoid these to keep your setup lean:

Avoiding eslint-plugin-prettier: You might see tutorials suggesting eslint-plugin-prettier, which runs Prettier as an ESLint rule. I generally advise against this. It slows down your editor and clutters your problem tab with red squiggly lines for simple spacing issues. Keep them separate.
Over-configuring Prettier: The beauty of Prettier is that it’s opinionated. The more you try to customize it, the more you’re just recreating the “formatting wars” you’re trying to escape. Accept the defaults where possible.
Ignoring .eslintignore: Always create a .eslintignore and .prettierignore file. You don’t want your tools trying to lint the node_modules folder or build artifacts.

Verdict: Which one do I use?

The answer is both. But if you are forced to choose one to start with, choose ESLint. Code quality and bug prevention are more critical than whether you use tabs or spaces. However, once your team grows beyond two people, Prettier becomes non-negotiable for maintaining sanity.