A formatting rule specifies how source code should look, not what it should do. Choices such as tabs versus spaces, quote style, and spacing around brackets do not improve runtime performance, but inconsistent choices make a shared codebase harder to navigate. A formatter applies one style consistently, reducing repeated decisions and team debates. section 4.2 section 4.2.1
Same code, different style
A filter expression can place its callback on the same line or a new line, include or omit parentheses around the callback parameter, and use single or double quotes. Prettier chooses a consistent form under its ruleset; when the expression grows, it can break the callback and conditions across lines. Consistent formatting does not, by itself, make the code well structured. 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 expression shows Prettier splitting a callback and its conditions when a single-line form becomes unwieldy. section 4.2.1
A practical Prettier setup has two core steps and two optional ones:
- Install the project package with `npm install --save-dev prettier`. section 4.2.3
- Add a root `.prettierrc` only if the default ruleset needs changing. section 4.2.3
- Install the Prettier integration for the team’s editors so formatting is available while editing. section 4.2.3
- If commits must meet the ruleset, add a precommit check for changed files; `lint-staged` is one option. This also catches changes made outside the editor or introduced by merges. section 4.2.3
Prettier is not the only option. ESLint has formatting rules, so check for conflicts when using both. StyleLint addresses style-related problems and can use a Prettier ruleset. EditorConfig supplies simpler project-wide rules, such as tabs or spaces, and can complement other tools. Choose enforcement to fit the project rather than treating every integration as mandatory. section 4.2.4 section 4.2.3
