ESLint and Prettier Setup: Fix Conflicts the Right Way

A file that changes every time you save is often caught between two tools enforcing different opinions. Turning off the linter makes the symptom disappear but can also remove valuable checks. A better repair identifies which tool owns formatting, which owns correctness, and where their configurations diverge.

Reproduce the conflicting change

Choose one file with repeatable churn. Save it twice, then run the formatter and linter separately. Capture the diff after each operation. If the second save reverses the first, an editor integration may be running an additional action that the terminal command never executes.

Use the JSON formatter to inspect sanitized package scripts or JSON-based formatter configuration. Paste strict JSON, not a JavaScript flat-config file. The goal is readable evidence: exact commands, exact extensions, and the smallest file that demonstrates the conflict.

Before editing rules, record the package versions from the installed dependency tree and the runtime version. Configuration advice for an older ESLint format may not apply to the project's installed major. Avoid copying a large preset simply because its name sounds compatible.

Give formatting one owner

Assign formatting ownership to Prettier if that is already the project's chosen formatter. Keep ESLint focused on issues such as unused variables, suspicious expressions, and framework-specific mistakes. Overlapping stylistic rules can produce noise without providing an independent safety check.

The Prettier integration guide explains the role of compatibility configurations. A compatibility package disables conflicting lint rules; it does not necessarily run Prettier or add a formatting command. Those are separate decisions with different performance and reporting tradeoffs.

{
"scripts": {
  "format": "prettier . --write",
  "format:check": "prettier . --check",
  "lint": "eslint .",
  "lint:fix": "eslint . --fix"
}
}

These scripts deliberately expose separate actions. A contributor can check formatting without rewriting files and can inspect lint fixes independently. Use the package manager already selected by the repository to invoke them; do not add a second lockfile while troubleshooting.

A compatibility configuration should be placed where its conflict-disabling settings win against earlier conflicting presets, according to the configuration system in use. Read the installed package's instructions rather than assuming one universal import name or order across every major version.

Inspect configuration discovery and scope

Follow the ESLint configuration documentation for the project's configuration mode. File scope matters as much as rule values. A preset might apply only to JavaScript while another block matches TypeScript, or a package may maintain a separate configuration entirely.

Use ESLint's configuration inspection options for the failing file. Compare that resolved result with the configuration you thought was active. This catches parent-directory settings, unmatched file globs, and rules introduced indirectly through shared presets.

Do the same with formatter discovery. A local configuration can override an editor preference, while an ignored file might never reach Prettier at all. Check the formatter's output channel and the actual executable version. A global installation is not reliable evidence of what the repository command uses.

Consider generated files separately. Formatting generated clients by hand is usually wasted effort because the next generation run replaces the result. Prefer an explicit exclusion or a generator option, and document why that directory is treated differently.

If only one package behaves differently, troubleshoot that package before replacing the root configuration. Workspace boundaries and working directories frequently explain an apparent contradiction. A fix that silences the entire monorepo can conceal the original mismatch.

Align editor actions with terminal checks

Make the editor call the same formatter that command-line checks expect. Turn off competing formatting providers for the affected language. If ESLint also runs fixes on save, verify that those fixes do not reintroduce formatting rules intentionally delegated elsewhere.

Save actions can run in a sequence that differs from a package script. Test them with one controlled change, then compare the result with running lint fixes followed by formatting. Do not assume a green status indicator means the saved file matches the repository's checks.

Use the VS Code formatting guide to review formatter selection and language-specific behavior. Document settings that are necessary for reproducibility, but leave harmless editor preferences local. Teams using multiple editors should still produce identical output.

For configuration snippets outside the linting system, structured-data tools can help inspect payload shapes, but they cannot determine whether an ESLint rule is appropriate. Keep tool-assisted formatting separate from semantic decisions about the codebase.

Record a clean baseline before enabling write operations. If an automatic fix removes code, changes import behavior, or alters a directive, examine that as a substantive edit. Formatting and lint fixes are not guaranteed to be equally safe or equally mechanical.

Roll out the repair without review noise

Use a two-part rollout: first correct the tooling configuration, then make any intentionally broad formatting changes in an isolated commit or pull request. Reviewers can verify policy independently from thousands of changed spaces.

Check a few representative file types, including Markdown, configuration files, and framework components. A JavaScript-only trial misses parser differences and embedded-language formatting. Keep examples small enough that another maintainer can repeat them quickly.

Add a short troubleshooting note to the contributor guide: the check command, the write command, the expected local dependency, and where to find editor logs. The Dev Tools guides provide general workflow context; project-specific commands still belong next to the source.

Avoid blanket suppression as the final repair. Disabling all rules or adding repository-wide ignore patterns can make checks pass while weakening feedback. Suppress a rule only when its behavior is understood and the exception has a narrow, documented reason.

After merging, ask a teammate with a different editor setup to run the same check. Agreement between independent environments is stronger evidence than repeated success on the machine where the fix was written. Keep the reproduction file or its relevant test if the conflict could return through preset upgrades.

Key takeaways

• Reproduce the conflict with separate formatting and linting commands.
• Let one tool own style and inspect resolved configurations for the failing file.
• Align save actions with repository checks instead of hiding the symptom.
• Separate tooling repairs from broad mechanical rewrites for clearer review.