Prettier Configuration with Claude Code

When Claude Code edits a project, formatting stops being a cosmetic detail. A single task can touch components, tests, JSON files, Markdown, and CI config. If indentation, quote style, line endings, and wrapping all change at once, the review becomes noisy before anyone can judge the actual behavior.

Prettier is an opinionated code formatter. In plain terms, it rewrites the visual shape of supported files without trying to decide whether the code is logically correct. That division matters: Prettier should handle layout, while tests, type checks, and ESLint should handle behavior and quality rules.

This guide shows a practical setup for using Prettier with Claude Code: local installation, .prettierrc, .prettierignore, npm scripts, VS Code settings, CI checks, staged formatting, and project instructions that tell Claude Code how to respect the rules. The examples are intentionally copy-pasteable for a typical npm-based JavaScript or TypeScript project.

The Workflow

Treat Prettier as a small quality gate that runs in several places, not as a cleanup command you remember at the end of a long session.

flowchart LR
  A["Claude Code edits files"] --> B["Prettier config defines style"]
  B --> C["Editor formats on save"]
  C --> D["npm run format:check"]
  D --> E["lint-staged formats staged files"]
  E --> F["CI checks the pull request"]

Each layer has a job. .prettierrc records the formatting policy. .prettierignore protects generated or irrelevant files. package.json scripts give humans, Claude Code, and CI the same command names. VS Code catches issues while you work. lint-staged keeps commits focused. CI prevents unformatted code from reaching review or main.

Claude Code should not have to infer formatting preferences from a conversation. Put the rules in files the agent can read, then ask it to run the same checks you run locally.

Install Prettier Locally

Install Prettier as a local development dependency. The official Prettier install guide recommends a local install with an exact version so every environment uses the same formatter behavior.

npm install --save-dev --save-exact prettier

Run a first formatting pass when you introduce the tool.

npx prettier . --write

For an existing product, keep that first formatting pass in its own commit or pull request. Mixing a repo-wide formatter diff with a feature change is one of the fastest ways to make a review slow and risky. After the baseline is merged, Claude Code can make smaller changes while Prettier keeps the shape consistent.

Add .prettierrc

Prettier supports several config formats, including .prettierrc, prettier.config.mjs, and a prettier key in package.json. The official configuration documentation explains that Prettier searches upward from the formatted file and intentionally avoids global configuration, which keeps formatting reproducible when a project moves between machines.

For beginners and mixed teams, a JSON .prettierrc is usually the clearest starting point.

{
  "printWidth": 100,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": false,
  "trailingComma": "all",
  "bracketSpacing": true,
  "bracketSameLine": false,
  "arrowParens": "always",
  "endOfLine": "lf",
  "overrides": [
    {
      "files": "*.md",
      "options": {
        "proseWrap": "always"
      }
    },
    {
      "files": ["*.yml", "*.yaml"],
      "options": {
        "singleQuote": false
      }
    }
  ]
}

printWidth is a hint to Prettier, not a strict maximum line length. endOfLine: "lf" reduces line-ending churn across Windows, macOS, Linux, and CI. trailingComma: "all" often makes later diffs smaller because adding one item to an array or object changes fewer lines.

Avoid adding plugins before you have a stable baseline. For example, prettier-plugin-tailwindcss is useful when Tailwind class order matters, but it also changes more output. First make the core formatter boring, then add plugins only when the project has a real need.

Add .prettierignore

.prettierignore tells Prettier which files not to format. Use it for build output, caches, generated files, and lockfiles controlled by package managers.

node_modules
dist
build
coverage
.next
.nuxt
.astro
.vercel
.cache
*.min.js
package-lock.json
pnpm-lock.yaml
yarn.lock

Prettier also follows .gitignore rules when run from the same directory, but .gitignore and .prettierignore have different purposes. Git ignore rules decide what should not be tracked. Prettier ignore rules decide what should not be rewritten. Keeping the generated and external files explicit helps Claude Code understand the boundary too.

A common failure is forgetting generated API clients. Claude Code may change one component, then prettier . --write formats thousands of lines under src/generated/. If the file is generated, fix the source schema and regenerate it. Do not let formatter churn hide the real change.

Add npm Scripts

The official npm docs describe scripts as the place where a package defines runnable commands. For a Claude Code workflow, scripts are important because the agent, the developer, and CI can all use the same names.

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

Use the write command locally and the check command in automation.

npm run format
npm run format:check

format modifies files. format:check exits with a failure if files are not formatted. That makes format:check the right command for CI. It gives a clear signal without letting CI silently rewrite code that nobody reviewed.

Configure VS Code

Editor formatting catches drift before it becomes a commit. Add workspace settings so the repo owns the editor behavior instead of relying on each developer’s personal defaults.

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "prettier.requireConfig": true,
  "[javascript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescript]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[typescriptreact]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[json]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  },
  "[mdx]": {
    "editor.defaultFormatter": "esbenp.prettier-vscode"
  }
}

prettier.requireConfig is worth enabling. It prevents the extension from formatting unrelated projects that do not declare Prettier. That is especially useful for consultants, agency teams, or anyone who opens many repositories with different conventions.

Check Formatting in CI

A minimal GitHub Actions workflow is enough to start.

name: format

on:
  pull_request:
  push:
    branches: [main]

jobs:
  prettier:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run format:check

This matters when Claude Code opens or updates a pull request. CI catches formatting drift before a reviewer spends time on the diff. If you also enforce code quality rules, pair this with the Claude Code ESLint configuration guide, but keep formatter and linter failures understandable as separate signals.

Format Only Staged Files

On a large repository, formatting everything on every commit can be slow and noisy. Use Husky and lint-staged when you want to format only the files selected for commit. The broader Git hook workflow is covered in the Husky + lint-staged guide, but this is enough for Prettier.

npm install --save-dev --save-exact husky lint-staged
npm pkg set scripts.prepare="husky"
npx husky init

Add lint-staged config to package.json.

{
  "scripts": {
    "prepare": "husky"
  },
  "lint-staged": {
    "*.{js,jsx,ts,tsx,css,md,mdx,json,yml,yaml}": "prettier --write"
  }
}

Then keep .husky/pre-commit simple.

npx lint-staged

The main benefit is scope control. If Claude Code edits three files, the pre-commit step formats those files instead of waking up old formatting debt across the whole repo.

Tell Claude Code About the Rules

Project instructions help Claude Code behave consistently. The official Claude Code memory docs describe ./CLAUDE.md and ./.claude/CLAUDE.md as shared project instruction files for commands, coding standards, architecture, and workflows.

## Formatting

- Read `.prettierrc` and `.prettierignore` before formatting files.
- Do not reformat unrelated files while implementing a feature.
- After changing JavaScript, TypeScript, CSS, Markdown, JSON, or YAML, run `npm run format:check`.
- Keep formatter-only changes separate from behavior changes.

Claude Code hooks can go further. The official hooks guide includes an example that runs Prettier after Edit or Write tool calls.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

Treat that hook as optional infrastructure, not as a first-day requirement. It depends on jq and shell behavior. On Windows-heavy teams, it can be simpler to start with explicit CLAUDE.md instructions and a required npm run format:check at the end of each task.

Three Practical Use Cases

Use case	Why Prettier helps	What to ask Claude Code
TypeScript product app	Components, tests, and utility types stay readable in one diff	Run npm run format:check after the change.
Astro or MDX content site	Frontmatter, Markdown, code fences, and JSON snippets stay consistent	Check that the MDX code fences are still valid.
Team pull request workflow	Reviewers can focus on behavior instead of indentation	Do not mix formatter-only changes with the feature diff.

The MDX case is the one I notice most. A single article can contain prose, YAML-style frontmatter, JSX, shell commands, and JSON. Without Prettier, Claude Code may produce content that is technically correct but visually inconsistent. With a shared formatter, the review shifts back to accuracy, examples, and structure.

Common Pitfalls

The first pitfall is using npx prettier . --write without installing Prettier. If the package is not in devDependencies, npx can temporarily fetch whatever version is current at that moment. Pin the formatter locally with --save-exact.

The second pitfall is making ESLint and Prettier fight. Prettier formats. ESLint should catch bugs and maintainability issues. If ESLint still enforces style rules that Prettier owns, use eslint-config-prettier or simplify the conflicting rules.

The third pitfall is formatting the whole repository inside a feature branch. If the baseline is messy, create one formatter-only change first. Then ask Claude Code to avoid unrelated formatting while implementing the feature.

The fourth pitfall is ignoring too much. A .prettierignore entry like src/** defeats the point of having a formatter. Ignore generated, cached, external, or very large files, not the code that humans review every day.

Monetization CTA

If you use Claude Code across multiple projects, the value is not only the .prettierrc file. The reusable asset is the operating system around it: CLAUDE.md, verification commands, review checklists, PR templates, and handoff notes. ClaudeCodeLab collects those materials on the products page so you can turn this setup into a repeatable team standard.

Summary

Prettier is a small but important foundation for Claude Code work. Install it locally, define .prettierrc, protect generated files with .prettierignore, expose format and format:check scripts, use VS Code for immediate feedback, run checks in CI, and use lint-staged when you only want staged files formatted. Then document the same expectations in CLAUDE.md so Claude Code knows how to behave.

Tested result: after applying this setup to a small TypeScript and MDX project, the first full formatting pass created a clean baseline, npm run format:check passed reliably afterward, and Claude Code-generated article edits became easier to review. The biggest practical wins were ignoring generated output and separating format from format:check.