Prettier automatically rewrites source code to follow a consistent formatting ruleset. Its opinionated defaults settle choices such as quotes, spacing, and line breaks without repeated team debates. Formatting primarily improves collaboration and developer experience; it does not make the resulting code faster or better structured. section 4.2 section 4.2.1
The formatter considers the shape of a statement, not just isolated spacing rules. A short filter expression can remain on one line; as its condition grows, Prettier splits the call and then the condition across lines. The behavior makes formatting predictable, though the result is not necessarily the most elegant way to organize the code. section 4.2.1 section 4.2
const someCars = originalListOfCars.filter(
(car) =>
car.make === "Fiat" &&
!car.isPickup &&
!car.isHatchback &&
car.cylinders >= 6
);
The longer filter condition shows Prettier placing each test on its own line under the default rules. section 4.2.1
A practical project setup has four steps:
- Install it as a development dependency with `npm install --save-dev prettier`. section 4.2.3
- Optionally add a root `.prettierrc` file to change supported defaults. For a one-off invocation, `prettier --use-tabs --no-semi src/` requests tabs and omits semicolons; not every internal rule is configurable. section 4.2.2 section 4.2.3
- Install the Prettier integration for your editor so formatting is available while you work. section 4.2.3
- Optionally enforce formatting before commits. A precommit hook can catch changes made outside the editor or formatting disrupted by a merge; `lint-staged` is one suggested approach. section 4.2.3
Check neighboring tools for conflicting responsibilities. ESLint can enforce formatting rules, so its rules must not compete with Prettier’s. StyleLint can use a Prettier ruleset, while EditorConfig supplies simpler baseline rules; neither makes Prettier the only viable choice. section 4.2.4
