ESLint and Prettier Conflict: How to Fix It

What Causes an Eslint and Prettier Conflict?

An eslint and prettier conflict happens when two tools make different decisions about the same line of code. Eslint wants one indentation or quote style. Prettier rewrites the file into a different shape on save. So the editor fills up with contradictory warnings.

This mostly shows up when you install both tools independently. Eslint is built to catch bugs and enforce quality rules. Prettier, however, automatically decides spacing, line breaks, and quote style. When both tools weigh in on the same decision, every save produces a fresh wave of warnings. As a result, the root cause is almost always a missing boundary between the two tools.

This friction never settles on its own, either. It resurfaces on every save, every commit, and every review. Over time, teams start to tune out the warnings. Eventually that habit hides a real bug in the noise.

For example, a team might ignore dozens of quote-style warnings every single day. In addition, new contributors often assume the project is simply broken when they see that many red marks. Therefore, fixing the root cause early matters more than it might first appear. Otherwise, that first impression can push a talented new hire to question the whole codebase unfairly.

What Does Eslint Actually Do?

Eslint is a static analysis tool for JavaScript and TypeScript. It flags unused variables, unreachable code, and risky comparisons early. It also lets a team enforce shared coding conventions, such as naming patterns or required function signatures.

Thanks to its plugin ecosystem, you can add rules for React, Vue, or Node.js. For that reason, Eslint goes far beyond formatting; it surfaces behavioral risk early, well before that risk ever reaches a production environment. So why does such a broad rule set clash with Prettier? Because a handful of Eslint's style rules overlap with decisions Prettier already makes on its own.

Indentation is a good example. If Eslint wants one width and Prettier applies another, that small mismatch turns into noise. In a large file, it can touch nearly every line, and developers start missing real bugs in that noise. For instance, a single misaligned indentation setting can generate hundreds of warnings in one pull request alone. Consequently, reviewers waste time scrolling past noise instead of reading the actual logic change.

What Does Prettier Actually Do?

Prettier is a code formatter that rewrites style according to one consistent rule set. You stop deciding indentation, quote type, and trailing commas yourself. Prettier reformats the file the moment you save it. The goal is to remove formatting debates from the team entirely.

This approach saves time in code review, since nobody comments on quote style anymore. It also keeps output identical no matter which editor each developer uses. However, Prettier never looks at logic, only appearance. So it does not take over Eslint's quality checks in any way.

Some developers treat Prettier as a personal preference instead of a team standard. Once a project grows, that habit creates noisy, unrelated diffs. Making Prettier mandatory from day one keeps the history clean for everyone. Otherwise, every contributor applies a slightly different style, and that inconsistency shows up in nearly every diff. In practice, this is one of the easiest wins a team can lock in early.

Why Do Teams Use Eslint and Prettier Together?

Most teams want both bug detection and consistent formatting. So they adopt both tools at once. Eslint protects code quality while Prettier ends formatting arguments. This pairing has become close to a default choice on larger, multi-contributor projects.

Running both tools side by side, though, does not guarantee harmony. Each tool ships its own formatting opinions out of the box. When those opinions diverge, conflicts pile up quietly. As a result, developers keep hitting a fresh list of warnings after every save.

Once you decide to combine the two tools, add a compatibility package to your setup checklist on day one. Otherwise the conflict starts accumulating right away, and cleaning it up later costs far more time. For example, teams that wait several months often spend an entire sprint just untangling accumulated warnings. So it is always cheaper to set this up correctly from the start.

Which Rules Usually Trigger the Conflict?

Conflicts typically appear in indentation, quote style, trailing commas, and line length rules. When Eslint's style rules do not match what Prettier applies, every save produces a new list of errors. For example, the indent rule is a textbook case, and the official eslint-config-prettier guide flags it directly.

• Indentation width and type, such as spaces versus tabs.
• Quote style preference, such as single versus double quotes.
• Trailing comma usage at the end of a line.
• Maximum line length rules.

This list keeps growing as a project scales. So instead of chasing each rule one by one, it is far more sustainable to block the conflict at its source.

What Does the Eslint Config Prettier Package Do?

Instead of disabling conflicting rules one at a time, the official Prettier documentation recommends eslint-config-prettier. It turns off every Eslint style rule that could clash with Prettier. Formatting then belongs entirely to Prettier, while Eslint stays focused on code quality.

The package also covers several plugin rule sets, such as those from TypeScript, React, or Vue. In other words, one small config addition closes off many potential conflict points at once. That protection keeps working even after you add new plugins later, and it adjusts automatically as your rule set grows over time.

One detail matters here: the package only turns rules off. It never adds formatting rules of its own. So you always need to pair it with another Eslint config as a base.

How Do You Install Eslint Config Prettier?

Installation takes a single command: npm i -D eslint-config-prettier. After installing it, add it to your Eslint configuration. In a classic .eslintrc file, add "prettier" to the end of the extends array. That way it overrides every conflicting rule that came before it.

If your project uses the newer flat config, that is eslint.config.js, import eslint-config-prettier/flat instead. Place it at the end of the array. Order matters here: putting it first lets later entries re-enable rules you just turned off.

Once installed, scan your project from top to bottom. Most of the old conflicting warnings disappear right away. Whatever remains is a genuine quality issue, not a formatting argument. In practice, this single pass often removes the majority of a project's open warnings in one sitting.

Should You Still Use Eslint Plugin Prettier?

Some teams reach for eslint-plugin-prettier, which runs Prettier as if it were an Eslint rule. The official Prettier documentation no longer recommends this in general. It surfaces formatting differences as red squiggly underlines, which floods the editor with noise.

It also runs slower than calling Prettier directly, and the extra layer can introduce its own bugs. This plugin made sense in Prettier's early years. Today, separating lint and format into distinct commands gives a simpler and faster result.

The official docs also mention prettier-eslint and prettier-stylelint. These help in rare cases where Prettier's output alone is not usable. They run Prettier first, then apply remaining Eslint rules. However, they run much slower than Prettier on its own. So try the standard compatibility package first, and only reach for these extra tools when you truly need them. Otherwise you risk adding a slower, heavier dependency for a problem the simpler fix already solves.

Is There a Difference Between Eslintrc and Flat Config?

Yes, the two formats work differently. You add eslint-config-prettier in a different way for each one. The legacy .eslintrc.* file relies on an extends array. The newer flat config, instead, is defined as a plain JavaScript array; the official Eslint configuration guide covers both formats.

So clarify which format your project uses before touching anything else. In a mixed setup, with both formats still lingering, the package often lands in the wrong spot. The conflict then keeps resurfacing. Since recent Eslint releases lean toward flat config, new projects are generally better off starting there.

When migrating an existing codebase, update the config gradually. That is safer than rewriting every rule at once. In practice, teams that migrate one package at a time catch mistakes early, before they spread across the whole repository.

Why Should You Run Lint and Format as Separate Steps?

The official Prettier source recommends running linting and formatting as two separate commands. That way, each tool does its own job: Eslint catches logic errors, Prettier handles formatting. This split also makes debugging easier, since you know right away which tool is responsible.

For example, prettier --check . verifies formatting as its own dedicated step. Most editors also run Prettier automatically on save. So formatting issues are usually resolved well before a commit even happens.

Once this separation becomes habit, team discussion changes entirely. Nobody argues about quote style anymore. Instead, every conversation moves straight to logic.

How Do You Detect Which Rules Are Conflicting?

The eslint-config-prettier package ships a helper command for this: npx eslint-config-prettier path/to/main.js. When it finds a conflict, the command exits with a different status code. It also lists exactly which rules are causing trouble.

Run this step while setting up a new project, or while updating an existing config. It saves you from comparing rules by hand. It is also worth rerunning any time you add a new plugin, since that quick check can catch an overlooked conflict early.

What Should You Watch for in Editor Integration?

Having both the Eslint and Prettier extensions active at once can get confusing fast. The cleanest setup leaves formatting entirely to Prettier on save. Eslint, meanwhile, stays dedicated to error and quality checks.

It also matters that every teammate shares the same editor settings. Otherwise, one developer's editor saves code one way, while someone else's produces a different result. Sharing these settings through a file committed to the project root removes that difference entirely.

Some teams lock this down with a shared editor configuration file at the root. Others simply document it and hope each developer applies it by hand. The first approach is far more reliable. A new teammate then inherits the correct settings the moment they clone the repository.

How Do You Enforce a Shared Standard Across a Team?

On multi-contributor projects, a shared standard depends on configuration files committed to the project root, not on individual preference. Once Eslint and Prettier settings live in version control, every contributor inherits the same rules automatically.

This removes "please fix the quotes" comments from code review entirely. A new developer also inherits the right setup the moment they clone the project. No separate onboarding guide is required. The team then spends its energy on real code quality instead of formatting debates.

Clients who skip this step early often end up with hundreds of warnings months later. Cleaning that up takes far longer than setting things up correctly in week one.

How Do You Check Formatting in a CI/CD Pipeline?

Add Eslint and Prettier checks as separate steps in your pipeline. This prevents poorly formatted code from reaching the main branch. A typical pipeline follows these steps:

1. Install dependencies, for example with pnpm install.
2. Run eslint . to check code quality.
3. Run prettier --check . to verify formatting.
4. Allow the merge only once both steps pass.

Keeping these two steps separate means you see right away which check failed. If it is a formatting issue, a developer simply runs Prettier and fixes it in one command. The pipeline then becomes two independent gates, one for quality and one for consistency.

Does the Conflict Risk Grow in Monorepo Projects?

Yes, the risk grows in a monorepo, where several packages live in one repository. Each package can carry its own Eslint configuration. Over time, those configurations can drift out of sync with each other. A shared configuration file at the repository root makes a real difference here.

If you rely on pnpm or npm workspaces, also confirm that the dependency tree resolves the same tool version for every package. Otherwise, one package ends up on an old Eslint version while another runs a newer one. Behavior then starts to diverge between them.

Checking this by hand across dozens of packages in a large monorepo is impractical and easy to get wrong. So most teams place a single compatibility config at the root and let every package inherit it.

What Mistakes Commonly Cause an Eslint and Prettier Conflict?

The most common mistake is installing both tools and never adding a compatibility package like eslint-config-prettier. In that case, the two tools fight each other indefinitely. Another frequent mistake is placing the compatibility config at the start of the extends array. That placement strips away its power to override anything.

• Never installing the compatibility package at all.
• Placing the compatibility config at the start of the list.
• Leaving both the old and new config formats half migrated.
• Never sharing editor settings across the team.

Each mistake looks small on its own. Together, though, they wear down developer patience fast.

A less obvious mistake is trying to fix every warning rule by rule. Some developers close one warning at a time by hand. That approach stops scaling once the project grows. The same issue then keeps reappearing in every new file. Installing the compatibility package correctly removes this repetitive work for good.

What Changes Once the Conflict Is Resolved?

Once the conflict is resolved, the unnecessary red warnings disappear. Every save then produces one consistent format. Developers stop losing time to formatting arguments. Instead, they redirect that energy toward real logic and code quality.

Code review also gets shorter, since formatting comments vanish entirely. New developers ramp up faster too, because the tooling already enforces a consistent standard on its own.

Many teams notice the change beyond the editor as well. Pull request review times shrink, because the conversation shifts straight to architecture and logic. That shift indirectly speeds up overall delivery. In the long run, this small change in habit compounds across dozens of pull requests every month.

Who Should Own This Setup on a Custom Software Project?

Getting this tool alignment right at the start of a custom project avoids a lot of wasted time later. Our team treats this kind of configuration as a standard step at the beginning of every custom software development engagement.

This approach guarantees that every developer who joins later works to the same standard. As the project grows, tool conflicts do not resurface, because the foundation was set correctly from day one.

Conclusion: How Do You Manage an Eslint and Prettier Conflict?

Resolving an eslint and prettier conflict for good means keeping the division of labor clear. Formatting belongs to Prettier. Code quality belongs to Eslint. Adding eslint-config-prettier in the right position keeps that split in place automatically.

Once you set it up correctly, the team never goes back to arguing about formatting. This small but lasting step improves developer experience for the entire life of the project. The setup time, in turn, pays for itself within the first few weeks of normal day-to-day development work.

How Do Eslint and Prettier Compare at a Glance?

The table below clarifies where each tool's responsibility ends. This makes the source of the conflict easier to spot.

Which Related Tools Do You Usually Pair With This Setup?

Eslint and Prettier setup often ties into your package manager choice too. For faster dependency resolution, see our what is pnpm guide. If dependency tree errors come up during setup, our npm eresolve fix guide covers that directly.

If your project is moving toward TypeScript, our TypeScript versus JavaScript comparison can help with that decision. For related interview-style questions, our React and JavaScript interview guide is also worth a look.

How Do You Share Tool Settings Through Version Control?

The most reliable way to share Eslint and Prettier settings is version control itself. For the basics, our Git and GitHub guide covers the essential commands. When two developers edit the same file and hit a conflict there too, our git merge conflict guide walks through the fix.

Planning to contribute to an open source project? Our open source contribution guide explains why most projects require exactly this kind of tool alignment first.

Do Environment Variables and API Communication Deserve the Same Care?

Yes, tool alignment is not the only setup detail worth getting right early. Secrets landing in a repository by accident is another common issue. We cover that in env file accidentally committed to git. For faster service-to-service communication, our what is gRPC guide is also worth a look.

Both topics, much like an eslint and prettier conflict, save real time down the line. That is true whenever they get configured correctly at the start, rather than patched later under pressure.

Does Formatting Performance Affect Site or App Speed?

Not directly, since Eslint and Prettier only run during development. They never ship as part of the production bundle. However, cleaner code tends to surface performance issues earlier. Our how JavaScript affects site speed article covers the kind of issue this tooling tends to catch sooner.

In short, formatting and quality tools do not boost performance directly. A clean, consistent codebase, though, saves time whenever you do sit down to optimize it. In addition, a tidy codebase makes it easier to spot where a slow function actually lives, instead of guessing across a messy file.