What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Choose one semicolon policy for the project, configure the formatter to apply it, and make the linter agree. If Prettier handles formatting, let it own semicolon style and disable conflicting ESLint formatting rules rather than having the tools rewrite the same code in opposite ways.
Why the formatter and linter keep disagreeing
A formatter changes code to match formatting options; a linter can report or automatically fix violations of its rules. If the formatter is set to omit semicolons while the linter requires them—or the reverse—running one tool after the other can undo the previous tool’s changes. The durable fix is to establish a single policy and align the tools that act on it.
Prettier recommends using it for formatting and linters for code-quality concerns. Its integration guidance points to eslint-config-prettier to disable ESLint rules that conflict with, or are unnecessary alongside, Prettier.
Choose the project’s semicolon policy
Before changing configuration, check the repository’s existing style and team convention. Neither semicolons nor a semicolon-free style is universally best; consistency across the project matters more than changing conventions while troubleshooting.
| Policy | Prettier setting | What it does |
|---|---|---|
| Use semicolons | semi: true |
Prints semicolons at the ends of statements. |
| Omit semicolons where safe | semi: false |
Omits statement-ending semicolons, while retaining leading semicolons where they may prevent automatic-semicolon-insertion hazards. |
These behaviors are documented in Prettier’s semicolon option. Put the choice in the project’s configuration file so contributors and automated runs apply the same policy. Prettier documents supported configuration files and project configuration in its configuration guide.
Align Prettier and ESLint
- Find every place that can set or change the style. Inspect the project’s Prettier and ESLint configuration, installed package versions, editor’s default formatter, and save actions. A correct project config may still appear ineffective if an editor invokes a different formatter or runs a conflicting fix-on-save action.
- Set Prettier’s policy in the project config. Use
semi: truefor semicolons at statement ends orsemi: falseto omit them except where a leading semicolon may be needed to avoid an ASI hazard. - Remove the conflicting lint formatting rule if Prettier owns formatting. Prettier recommends
eslint-config-prettierto turn off rules that conflict with its formatting. Keep ESLint rules that address correctness and code quality. - Check the project’s ESLint version and rule source. ESLint’s core
semirule documentsalwaysandnever, but the rule page marks it deprecated since ESLint v8.53.0. Don’t assume an old configuration example describes the rule or plugin your project currently uses; check the installed version and active configuration. - Run both tools, then test save behavior. Format a representative file and run the linter. If each command passes independently but saving creates repeated diffs, inspect editor-on-save settings for multiple formatters or lint fixes that enforce different styles.
For the exact Prettier/ESLint division and integration advice, see Prettier’s integration guide and ESLint’s semi rule documentation.
Why semicolon-free JavaScript can still contain semicolons
JavaScript’s automatic semicolon insertion (ASI) handles many statement endings, but not every line break means the preceding statement has ended. A next line beginning with certain tokens can continue the prior expression instead. ESLint’s no-unexpected-multiline documentation highlights continuation-sensitive tokens such as [, (, +, *, /, -, and ..
That is why Prettier’s semi: false option can still produce a semicolon at the beginning of a line: the leading semicolon can separate a new expression from the one above and avoid an ASI-related misinterpretation. A linter rule set to forbid every semicolon may therefore disagree with Prettier even when ordinary statement endings look consistent.
Quick Recap
Best Value
Rank #3
If the conflict persists
- One command undoes the other: Recheck the active formatter and lint rule. Choose one owner for formatting and disable the opposing stylistic rule.
- Command-line runs are clean, but saving changes the file: Inspect the editor’s default formatter and save actions; multiple tools may be running on save.
- The config looks right, but the lint result differs: Confirm the installed ESLint version and which rule or plugin supplies the semicolon rule before adapting configuration examples.
- A leading semicolon appears in a semicolon-free project: It may be protecting an ASI-sensitive line boundary, not indicating that Prettier reverted the project’s policy.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
