ESLint vs. Prettier: History, Conflict, and the Deprecation of Formatting Rules

Hello everyone, I am Kasong.

Anyone who has configured code formatting has probably wondered whether to use Eslint or Prettier —both can format code style—or whether to use them together.

From now on you don’t have to worry about this any more because the Eslint team has compromised. According to the official blog[1], starting from v8.53.0 the "code‑style related rules" in Eslint will be deprecated.

The reason is not purely technical; market forces play a big role.

This article explains the whole story.

Eslint’s Rise

Before 2013, front‑end engineers usually used JSLint or JSHint as "code checkers" to detect:

Code quality issues (e.g., avoid eval() , use === instead of == ).

Code errors such as undefined variables or type‑conversion problems.

JSLint parses the code with an internal JavaScript parser and analyses the token stream. JSHint is derived from JSLint and adds a configurable .jshintrc file.

Both tools can check code, but because of their implementation they cannot perform complex rule checks and provide little style checking.

During that period, code‑style checks (indentation, line length, quote style, semicolons, etc.) were mainly handled by JSCS .

In 2013 Eslint was released. It parses code into an AST and analyses it, which preserves more context than JSHint or JSLint . This enables more complex rule validation and allows developers to write custom plugins.

Compared with JSHint or JSLint , the AST retains more code context.

Therefore Eslint can perform sophisticated rule checks and also supports "automatic code fixing" for style violations.

Because of its advanced features and the author’s reputation (the author of the "Red Book"), Eslint gradually displaced its competitors.

Eslint vs. Prettier Conflict

Although Eslint provides many rules, not every developer wants to maintain a custom rule set. Over time, best‑practice rule collections such as the Airbnb rules[2] and the standard rules[3] emerged.

Developers usually extend these collections to form a project‑specific lint configuration, which typically includes three categories:

Code quality checks

Code error checks

Code style checks

Code‑style checks are highly subjective. Different team members may have different style configurations, which harms the readability of git diff output.

To enforce a consistent style, Prettier appeared. It is a "opinionated" formatter with a fixed style set and limited configurability.

The low configurability is a double‑edged sword: it enforces consistency but makes custom style tweaks difficult.

For example, Prettier ’s printWidth forces line wrapping, which can break the readability of git diff . Prettier does not provide an option to disable this behaviour.

Two solutions have emerged:

Solution 1: Use Eslint + Prettier together

Eslint handles quality and error checks, while Prettier handles style. Advantages: covers both aspects. Disadvantages:

Potential rule conflicts and high configuration cost.

Low configurability of style checks (because of Prettier ).

Solution 2: Use only Eslint

Manage style rules with a dedicated collection such as @stylistic/eslint-plugin-js [4] and use other Eslint rules for quality. This approach is simpler and highly configurable.

Clearly Solution 2 is preferable, so why does the Eslint team plan to deprecate all "code‑style related rules"?

The Eslint Team’s Compromise

When new language features appear, the associated rules usually include a few quality rules, a few error rules, and many style rules. The first two categories are more important than the third.

In ESLint’s early days, to attract JSCS users, ESLint had to implement all style rules supported by JSCS . Today, ESLint is the dominant JavaScript "code checker" and no longer needs to satisfy every community demand.

Rule Conflicts

Ideally, core rules should not conflict, but as the number of rules grows, conflicts become inevitable.

Consistency Issues

ESLint rules cannot access each other’s data, which can prevent correct automatic fixes. For example, an auto‑fix that adds a new line must know the file’s indentation, which is controlled by the indent rule.

Conclusion

From v8.53.0 onward, Eslint will deprecate the "code‑style related rules" because maintaining them offers a low return on investment for the core team.

The core team will focus on quality and error rules, while style rules will be bundled into external configurations or "development philosophies" (e.g., Airbnb style guide).

The real beneficiaries are the teams that market these philosophies, not the ESLint core contributors.

References

[1] Official blog: https://eslint.org/blog/2023/10/deprecating-formatting-rules/

[2] Airbnb rules: https://airbnb.io/javascript/

[3] Standard rules: https://standardjs.com/

[4] @stylistic/eslint-plugin-js: https://www.npmjs.com/package/@stylistic/eslint-plugin-js