I've been setting up a new dev environment for a SaaS project. Using VS Code with the Prettier extension for consistent formatting across the team.
But I'm running into a problem where the built-in formatter seems to be taking over, especially for JSON and CSS files. Even with "Editor: Default Formatter" set to Prettier, it sometimes ignores my `.prettierrc` settings.
Has anyone found a reliable way to lock Prettier as the absolute default for all file types? I've checked the workspace settings, but the behavior seems inconsistent.
I'm a community moderator at a 200-person B2B SaaS, and we've standardized on Prettier across our full TypeScript/React/Node stack to keep code reviews focused. I manage the formatting setup for the dev team, so I've wrestled with this exact issue.
Here's a breakdown of what worked for us:
1. **Extension order matters.** The built-in formatter often activates on file type if no other formatter is explicitly set for that language. You need to go into VS Code's settings.json and set `"[css]": { "editor.defaultFormatter": "esbenp.prettier-vscode" }` for every language you use, not just the global default. JSON, CSS, and HTML are the usual culprits.
2. **Workspace vs. User settings conflict.** If you have a `.vscode` folder in your project, its settings override your personal ones. Check there for any `editor.defaultFormatter` or `editor.formatOnSave` rules that might be resetting things. Inconsistency usually means a conflict between these layers.
3. **The Prettier extension's own resolution.** The extension can fall back to VS Code's formatter if it can't parse or apply your `.prettierrc` correctly. We saw this with trailing commas in JSON; a malformed config file (even extra commas) caused silent reversion. Run `npx prettier --check .` in your project root to see if Prettier itself flags any config issues.
4. **Format-on-save race condition.** With `editor.formatOnSave` true, sometimes the built-in formatter wins if the Prettier extension is still loading or has an error. Setting `"editor.defaultFormatter": null` for specific languages in your user settings can act as a blocker, forcing VS Code to only use the one you've set in the workspace.
My pick for a reliable setup is to explicitly define the formatter per language in your workspace `.vscode/settings.json`, and pair it with a root-level `.prettierrc` that's validated by a pre-commit hook. For a team, this eliminates machine-specific overrides. If you're working solo, just tell us if you're using any other linting/formatting extensions that might be interfering, and whether this is a monorepo or a single-project setup.
—HR
You've already set the global default, but VS Code's language-specific defaults can override it. You need to explicitly set Prettier for each file type in your settings.json, like "[css]" and "[json]". It's one of those hidden "features" that makes a simple task surprisingly fragile.
Your stack is too complicated.
That global setting is the first step, but you're right, it doesn't always stick. The inconsistency you're seeing is often because VS Code has individual default formatters for each language ID.
You'll need to explicitly override them. In your user or workspace settings.json, add entries for each language, like `"[json]": {"editor.defaultFormatter": "esbenp.prettier-vscode"}` and the same for css, html, javascript, etc. It's tedious, but that's what finally made it reliable for our team.
Also, double-check that you don't have another extension, like a CSS-specific one, registering itself as a formatter and creating a conflict.
—HR
Ah, the workspace vs. user settings conflict you mentioned is something I've definitely bumped into! I think I might have a `.vscode` folder from an old project template that's messing things up without me realizing it.
Do you find it's better to just delete the workspace settings entirely and let the team rely on their individual user settings with a shared `.prettierrc`, or is having that enforced `.vscode` folder actually helpful for consistency?