If one project needs a different code formatter, set the choice at the project level: use that project’s configuration file and, if you work in Visual Studio Code, its workspace settings. This keeps your VS Code user defaults intact while making the project’s formatting choice repeatable. The steps below focus on macOS and VS Code; other editors may use different controls.

Decide what “formatter” means for this project

First identify the language and the actual need. A formatter rewrites code to a style; a basic editor setting may only control indentation, line endings, or whitespace. For example, EditorConfig provides project style properties that participating editors can read, while Prettier is a formatter with its own project configuration. These tools can complement each other, but an EditorConfig file alone does not select or install a formatter. EditorConfig describes its format and editor plugins; Prettier’s configuration guide explains how it reads supported configuration files.

Check which formatter is already used by the project before adding another. Look at its package manifest, formatter configuration, and project documentation. If teammates or automated checks expect a particular tool or version, matching that setup is usually the most practical choice. Installing a competing formatter or changing its options can produce large diffs even when the code still works.

Choose where the setting belongs

In VS Code, user settings apply across your use of the editor, while workspace settings apply to the opened project and take precedence over user settings. VS Code keeps workspace settings in a .vscode folder at the project root; user settings are stored separately in your macOS account’s application support directory. Use the Command Palette (⇧⌘P) and choose Preferences: Open Workspace Settings (JSON) to edit the project setting. Confirm the Settings editor says Workspace before changing anything. VS Code’s settings documentation explains the scopes and locations.

To pick a formatter just for a language in this project, add a language-specific default formatter entry to the workspace settings. For example, if the project uses the Prettier VS Code extension for JavaScript, the setting has this shape:

{
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

Use the extension identifier for the formatter actually installed in your editor; the example is not a universal identifier. If the project includes multiple languages, add an entry for each relevant language rather than setting a global default. VS Code’s Format Document With... command lets you choose among available formatters for the current document, and its format actions can be invoked from the Command Palette. VS Code’s formatting guide documents those controls. Avoid enabling format-on-save as part of this narrow change unless you want every save in that project to trigger formatting.

Keep the formatter’s rules with the project

A default formatter selects a tool; it does not define all of that tool’s formatting rules. Store shared rules in a configuration file the chosen formatter recognizes. For Prettier, that could be a .prettierrc.json file at the project root. A minimal example might specify only the options the project has agreed to use:

{
  "singleQuote": true
}

Prettier searches from the file being formatted up through its parent directories for configuration, so a root-level config can serve files beneath it. It also supports several other configuration formats; choose one supported by the project’s version and existing tooling. Prettier’s configuration documentation lists the supported files and resolution behavior.

If the goal is only consistent indentation or line endings across editors, consider a root .editorconfig instead. For example, root = true stops the search for more distant EditorConfig files, and properties such as indent_style, indent_size, and end_of_line can define basic text conventions. Editor support varies by plugin, and these properties do not replace language-aware formatting rules. The EditorConfig specification and overview describe how files are found and how matching rules are applied.

Verify the scope before you format

Save the workspace setting and configuration, then reopen the project folder in VS Code if needed. Open one representative file and use Format Document With... to confirm the selected formatter. If the formatter is not listed, check that its extension is installed and supports that language; a workspace setting cannot install an extension or add formatter support by itself.

Before applying formatting broadly, inspect the affected files in Source Control or a diff view. Format a small representative set first, especially if the project has existing style rules or generated files. If the output is unexpected, stop and check for a competing configuration in a parent directory, a language-specific setting, or another formatter that the project already expects. Revert an unwanted formatting change through the editor’s source control tools, then adjust the project configuration and repeat on a small set.

This keeps the decision attached to the project: VS Code’s user defaults remain in their separate scope, while the project can carry its own formatter selection and rules. If you switch editors, the workspace setting will not follow you, so rely on the formatter’s project configuration when that editor supports it.

Sources