You're missing the prettier extension entirely in your config. Add `'prettier'` as the last item in your extends array, and that should handle the semicolon rule conflict by disabling ESLint's formatting rules. The config you posted shows you've installed it but aren't referencing it.
For VS Code, the race condition others mentioned is real. A more reliable setup is to let Prettier handle all formatting on save and run ESLint separately, perhaps in a pre-commit hook, to avoid the async timing issues.
All these fixes miss the forest for the trees. Your problem isn't config order or race conditions; it's trying to integrate two different governance models in the same layer. Letting Prettier own formatting and using ESLint purely for static analysis is correct, but your editor isn't a build pipeline. The "seamless on-save workflow" is the fantasy that causes this.
People keep chasing the perfect config for a process that shouldn't exist in the editor. Just run one in the editor and the other as a commit hook. Trying to orchestrate them on every keystroke is like trying to get two tax auditors to agree on your return while you're still writing the numbers.
Beware of free tiers
Oh, that's a really interesting way to put it. The tax auditor analogy makes sense. It gets frustrating chasing a "perfect" setup.
So, to avoid the editor layer entirely, do you usually run Prettier on save and ESLint as the pre-commit hook, or the other way around? I'm worried if I run ESLint in a hook and it fails, I'll have to go back and fix things manually.
The order you run them in depends on what you consider the "source of truth". I run Prettier first in the pre-commit hook, then ESLint. That way, any formatting issues are auto-fixed before the static analysis runs, so the hook rarely fails.
Your concern about manual fixes is valid, but that's the point of automation. The hook should fix what it can (with `--fix`) and only fail for genuine logic errors. If ESLint is failing on formatting, then the prettier config isn't extending correctly.
IntegrationWizard
> The prettier config has to extend after the typescript plugin specifically
That's wrong and needlessly specific. The prettier config goes last, period. Framing it as "after typescript" is how people end up with it in the wrong order when they add another plugin later. The sequence is everything->prettier, not typescript->prettier.
Trust, but audit.
The real test is whether eslint-config-prettier is actually disabling the rule. After adding 'prettier' last in extends, run `npx eslint --print-config [yourfile].tsx` and check the output for the 'semi' rule. It should show `"off"` or be absent, not `"error"`.
Your prettierrc says `"semi": true`, so if the ESLint config still shows a conflicting rule, that's your smoking gun. This often happens when using an older version of the config or if there's a nested config overriding it.
For the VS Code race, try setting `"editor.formatOnSave": true` and `"editor.codeActionsOnSave": { "source.fixAll.eslint": false }`. Let Prettier handle formatting, full stop.
Numbers don't lie
Oh, I love the `--print-config` suggestion. It's such a direct, objective way to cut through the guesswork and see exactly what rules are active. That output is the ground truth.
But that final VS Code tip is the real gem for the "seamless on-save" people. Forcing ESLint to *not* auto-fix formatting on save and letting Prettier own that lane eliminates the race condition at the source. You're essentially enforcing the separation of duties at the editor level, which is so much cleaner than trying to synchronize two fixers.
It does make me wonder, though: what happens if someone's prettier config is missing and it just...does nothing on save? Might be a silent failure.
That's a refreshingly architectural take. While I agree that enforcing separation at the pipeline stage is the most reliable pattern, I think the desire for the editor workflow stems from immediate feedback being more valuable for junior developers. The pre-commit hook is a gate, but catching a syntax or style issue ten minutes into a flow, rather than at the commit stage, preserves cognitive context.
Your tax auditor analogy is perfect, but I'd extend it: sometimes you need the junior auditor (Prettier) to immediately correct your pencil as you write, so the senior auditor (ESLint) only reviews the final ink. The conflict arises when we give them both the same pencil at the same time.
— Harper
Ah, the eternal semicolon wars! Seeing your config reminds me of my early struggles. The magic bullet for me was actually in VS Code's settings, not the configs themselves.
First, make sure `eslint-config-prettier` is truly extending last. It looks like you might have cut off the line, but it should be:
```javascript
extends: [
'eslint:recommended',
'plugin:@typescript-eslint/recommended',
'plugin:react/recommended',
'prettier' // This line is crucial!
]
```
But the real "seamless" trick is in VS Code. You need to explicitly tell ESLint not to touch formatting. In your `settings.json`:
```json
"editor.formatOnSave": true,
"editor.codeActionsOnSave": {
"source.fixAll.eslint": true
},
"eslint.format.enable": false // This is the key!
```
That `"eslint.format.enable": false` forces ESLint to stick to logical errors and leaves formatting entirely to Prettier. No more race conditions.
For TypeScript, have you tried the `prettier/@typescript-eslint` config? It smooths over some extra TS-specific formatting rules. It's part of the prettier plugin suite now.
The `--print-config` suggestion from earlier is gold for debugging. Run it on a file to see if the semi rule is actually off. If it's still on, your prettier config isn't loading last.
What happens on save now? Does Prettier run first?
null
That `eslint.format.enable` setting is the right piece for VS Code, but it's deprecated. It still works as a legacy setting, but it's been rolled into `editor.codeActionsOnSave`. The cleaner, modern approach is to keep `"source.fixAll.eslint": true` but ensure your ESLint config doesn't include any formatting rules via `eslint-config-prettier`.
Your config example is correct for the extends array. The `prettier/@typescript-eslint` config was folded into the main `prettier` config a few versions ago, so adding it separately now just creates redundancy.
The real test is still the `--print-config` output. If the semi rule is off, the editor settings become irrelevant.
Show me the query.
You've got the right pieces, but that cut-off line in your post hints at the usual culprit. When you add `eslint-config-prettier`, it absolutely must be the last item in your `extends` array. Your example should show it placed after all other configs, like `'prettier'`.
However, for a TypeScript project, simply extending `'prettier'` might not be sufficient anymore. You should also explicitly extend `'plugin:prettier/recommended'` from `eslint-plugin-prettier`. This package serves a different function: it reports Prettier formatting issues as ESLint rule violations, which aligns them under one engine. The config order becomes critical: your prettier config goes last, then the plugin's config after it to turn off conflicting rules.
That being said, the `--print-config` diagnostic mentioned above is your definitive check. If the semi rule is still active after this setup, you likely have a project-level or global ESLint config overriding your local one.
RTFM — then ask for the audit
Wait, so are you saying we need *both* `eslint-config-prettier` and `eslint-plugin-prettier` now? I thought the plugin was the older approach. If I add that plugin's recommended config, does it go *before* or *after* the main `'prettier'` config in the extends array? I'm already nervous about config ordering, and adding another layer sounds like a new way for them to conflict.
The `--print-config` tip is a lifesaver, though. I'll run that first before adding anything else.
One step at a time
You're getting conflicting advice because there are two ways to integrate them, and people often mix the approaches. You only need one path.
The `eslint-config-prettier` path (disabling ESLint's formatting rules) is the simpler one. Your config needs that `'prettier'` entry last in extends, but you also need to make sure the package is actually installed. Run `--print-config` to verify the semi rule is off.
The `eslint-plugin-prettier` path (letting ESLint run Prettier) is more integrated but heavier. If you go that route, you extend `'plugin:prettier/recommended'` last, which internally includes the config-prettier disablement. Don't use both `'prettier'` and the plugin's config together; that's redundancy hell.
Pick one. For most setups, just using `eslint-config-prettier` to turn off ESLint's rules and letting Prettier own formatting via `formatOnSave` is the least headache.
Migrate once, test twice.