What Prettier does—and what it does not
Prettier formats code according to a consistent set of rules. It can settle recurring questions about spacing, line breaks, quotes, and trailing commas without requiring each contributor to make those choices by hand. In a JavaScript project, it can also format common related files, including JSON, CSS, and Markdown. It chooses a parser from a file’s extension, so you usually do not need a separate command for each file type.
Formatting is different from checking whether code works. Prettier will not find every bug, explain a confusing variable name, or replace a linter or tests. Its job is narrower: make supported files follow the same layout. That makes changes easier to review because contributors spend less time adjusting one another’s formatting.
Install it in the project
For this setup, use a JavaScript project with Node.js 18 or newer and npm installed. The commands below target Prettier 3.x. From the folder containing package.json, run npm install --save-dev --save-exact prettier@3. This adds Prettier as a development dependency, records the selected version in package.json, and updates the npm lockfile. Commit both files so other contributors can install the project’s chosen version.
A local installation is preferable to relying on someone’s global Prettier installation: the project declares the tool it needs. In an existing checkout with a committed package-lock.json, a contributor can use npm ci to install the recorded dependencies. If you do not yet have a package.json, run npm init -y in a new project folder first.
Choose a small shared configuration
Create a file named .prettierrc.json at the project root. For example, its complete contents can be {"singleQuote":true,"semi":true,"trailingComma":"all"}. These options tell Prettier to prefer single quotes where applicable, keep JavaScript semicolons, and add trailing commas where its parser supports them. The example is a preference, not a universal best practice; a team can choose different values. What matters most is keeping one configuration in the repository rather than relying on individual editor settings.
Consider adding a .prettierignore file if the project generates files that should not be reformatted. Put dist and coverage on separate lines, for example, if those folders contain generated build output and test reports. Prettier already ignores node_modules by default. Before ignoring another directory, check whether it contains source files that contributors should format. An ignore rule that is too broad can quietly leave part of a project inconsistent.
Add repeatable commands
Run npx prettier . --write from the project root to format supported files under that folder. Review the resulting changes before committing them, particularly the first time you run it in an older project. A first formatting pass may touch many files even when no behavior has changed.
For everyday use, add two entries to the scripts object in package.json without removing any scripts already there: "format": "prettier . --write" and "format:check": "prettier . --check". Then npm run format updates files, while npm run format:check reports files that need formatting without rewriting them. The check command is useful before a commit and in a continuous integration workflow because it exits unsuccessfully when it finds formatting differences.
Keep formatting changes focused when possible. If a project has substantial existing code, agreeing on and committing one baseline formatting pass makes later diffs easier to read. After that, contributors can format as they work and use the check command to catch missed files.
Keep editor behavior aligned
Many editors can run Prettier when you save a file. That can be convenient, but editor automation should complement the project commands rather than replace them. A contributor who uses another editor can still run npm run format, and the shared configuration gives both workflows the same formatting choices.
If a file appears unchanged after formatting, first check its extension and whether it matches a rule in .prettierignore. If two contributors get different results, check that they installed dependencies from the repository and are running its local Prettier version. For a quick final check, run npm run format:check from the project root. A consistent setup needs only a declared dependency, a shared configuration, sensible exclusions, and commands anyone can repeat.
