EditorConfig and Prettier: Keep Code Style Consistent

EditorConfig and Prettier solve different parts of the same problem. .editorconfig aligns basic editor behavior such as indentation, line endings, charset, and final newlines. Prettier parses supported files and rewrites formatting. They are complementary, not competitors.

The durable setup is: EditorConfig for file-level baseline, Prettier for code layout, ESLint for correctness and project rules.

Responsibility split

Prettier can read .editorconfig and map compatible options. More specific Prettier configuration wins, so keep indentation and line width decisions aligned.

Recommended .editorconfig

Create this at the repository root:

root = true

[*]
charset = utf-8
end_of_line = lf
insert_final_newline = true
indent_style = space
indent_size = 2
trim_trailing_whitespace = true
max_line_length = 100

[*.md]
trim_trailing_whitespace = false

[Makefile]
indent_style = tab

root = true stops the editor from continuing to search parent directories. Markdown often gets a separate rule because trailing spaces can be used for explicit line breaks.

Recommended Prettier config

Use a committed project config such as .prettierrc.json:

{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": false,
  "singleQuote": true,
  "trailingComma": "all"
}

Do not rely on a developer's global Prettier preferences. A cloned repository should format the same way on another machine.

Ignore generated files

Create .prettierignore:

.next
dist
coverage
node_modules
public/search-index-*.json
package-lock.json

Generated files should usually be maintained by the generator. Formatting them on every commit creates noisy diffs.

Whether to ignore lockfiles depends on the package manager and team policy. The important part is to choose deliberately.

Package scripts

{
  "scripts": {
    "format": "prettier . --write",
    "format:check": "prettier . --check"
  }
}

Run npm run format locally to fix formatting. Run npm run format:check in CI to fail without modifying files.

ESLint boundary

Prettier should own formatting. ESLint should own code quality and framework rules. Avoid making both tools fight over quotes, indentation, semicolons, and line wrapping.

A practical CI flow:

1. Type check.
2. Lint.
3. Run format:check.
4. Run tests or build.

If you use hooks, keep them lightweight enough that developers do not bypass them. Commit message rules are covered in Git Commit Rules with Husky and Commitlint.

VS Code settings

A repository can include .vscode/settings.json:

{
  "editor.formatOnSave": true,
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.codeActionsOnSave": {
    "source.fixAll.eslint": "explicit"
  }
}

Shared editor settings are useful, but CI is still the source of truth. Do not assume everyone uses the same editor or extension version.

Common conflicts

• Indentation keeps changing: align .editorconfig indent_size and Prettier tabWidth.
• Editor output differs from CLI: make the editor use the project-local Prettier version.
• A subfolder behaves differently: check nested config files.
• Markdown tables change too much: decide whether that file should be ignored.
• CI fails but editor looks fine: run the exact same CLI command locally.

Related FreeMac guides

• For broader config files, read Front-End Config: Env, Node, Git, ESLint, and TypeScript.
• For Git commit rules, read Git Commit Rules with Husky and Commitlint.
• For pnpm workflows, see Replacing npm with pnpm: A Complete Migration Guide.