Add as preferred on Google
What Is a VPAT and Why Do Companies Ask for It?Read More
Problems with Ignoring Formatting and Linting in React and How to Get Back on Track
Suppose you’re working on a React project with a team, whether at a growing startup, an agency juggling multiple clients, or a larger codebase that’s evolved over time. In that case, it’s tempting to skip tools like ESLint and Prettier when you’re racing against deadlines. After all, they don’t directly add features or fix bugs. But over time, skipping them quietly builds up friction that slows everyone down. By the time the chaos is visible, the mess has already taken root.
If you’ve ever jumped into a project and wondered why some files look like they were written in two different time zones by people who don’t talk to each other, you’ve seen what happens when formatting and linting aren’t enforced.
This blog covers why consistent code formatting and linting matter, how to introduce them into your project without creating chaos, and a few practical ways to clean up existing issues without halting progress.
Why Prettier Isn’t Optional
Prettier automatically formats your code according to a single style so that everyone on the team writes code the same way, no matter their personal preferences. It does this to settle once and for all the disputes of “tabs versus spaces”.
Without it, you'll run into:
- Random formatting differences across files—semicolons in some places, missing in others. Two-space indents here, four-space indents there.
- Code reviews bogged down with formatting nitpicks instead of meaningful discussion.
- A growing list of inconsistencies that slows you down and makes onboarding new teammates harder.
You won’t feel the pain immediately. But six months down the road, those tiny inconsistencies become friction points that cost time and mental energy.
Setting Up Prettier
If you’re starting fresh, it’s simple to add Prettier to your project. Visit the Prettier docs to install it and customize its behavior. You can run prettier with --write flag to automatically format your code according to your specified prettier rules:
yarn prettier --write .
Or, for specific folders:
yarn prettier --write "src/**/*.js"
To check for unformatted files without modifying them, you can run prettier with --check flag:
yarn prettier --check .
Once it’s in place, you can focus on writing code instead of formatting it.
Why ESLint Deserves a Spot in Your Workflow
Prettier formats. ESLint protects. It catches actual issues like unused variables, unreachable code, or inconsistent logic. It helps enforce rules and patterns that prevent bugs from sneaking in.
Skipping linting leads to:
- Small problems that gradually become bigger ones.
- A codebase that relies too much on each developer’s personal code style.
- Slower onboarding, because new team members don’t have clear guidance on structure or expectations.
Using ESLint to Fix Problems Automatically
You can use ESLint’s --fix flag to clean up some issues automatically:
yarn eslint . --fixOr target only specific files:
yarn eslint "src/**/*.js" --fix
More on setting up eslint in the ESLint docs.
Make It Automatic: CI and Pre-Commit Hooks
No one wants to manually run Prettier and ESLint every time they make a change. The solution? Automate everything.
1. Add Checks to CI
Set up your CI pipeline to block pull requests that don’t pass lint or formatting checks. This keeps the main branch clean and saves reviewers from having to ask, “Did you run Prettier?”
Here’s an example GitHub Actions workflow:
name: Lint and Format
on: [pull_request]
jobs:
lint-and-format:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install dependencies
run: yarn install
- name: Run Prettier
run: yarn prettier --check .
- name: Run ESLint
run: yarn eslint . --ext .js,.jsx,.ts,.tsx
2. Use Pre-Commit Hooks
Tools like Husky let you run ESLint and Prettier before a commit even goes through. If the code doesn’t meet your rules, the commit gets blocked. It’s a lightweight safeguard that makes a big difference over time.
Prettier provides an elaborate list of options to add it to pre-commit hook.
What If Your Project Is Already a Mess?
If you’re working in a big repo that never had formatting rules to begin with, adding Prettier and ESLint all at once can cause chaos: thousands of lines changed, unmanageable diffs, and even the risk of breaking working code.
Clean Up Incrementally: One PR at a Time
Only run formatting and linting on files changed in the current branch. That way, every pull request nudges the project closer to consistency without flooding your version history with unrelated changes.
Here’s how to set that up:
Step 1: Identify changed files
Add a script to your package.json to list changed files:
"get-changed-files": "git diff --name-only --diff-filter=d main...HEAD -- 'src/*.{js,ts,jsx,tsx}' > changed_files.txt"
Step 2: Lint and format only those files
Create a shell script (lint-changed-files.sh) to run Prettier and ESLint on the listed files:
#!/bin/bash
BATCH_SIZE=1200
while read -r file; do
files+=("$file")
done < 'changed_files.txt'
if [ "$1" == "fix" ]; then
PRETTIER_CMD="prettier --write"
LINT_CMD="eslint --fix"
else
PRETTIER_CMD="prettier --check"
LINT_CMD="eslint"
fi
for ((i = 0; i < ${#files[@]}; i += BATCH_SIZE)); do
batch=("${files[@]:i:BATCH_SIZE}")
yarn ${LINT_CMD} "${batch[@]}"
yarn ${PRETTIER_CMD} "${batch[@]}"
done
Then create a convenience command in your package.json:
"lint-diff": "yarn get-changed-files && lint-changed-files.sh"
Run it like this:
# Just check formatting/linting
yarn lint-diff
# Or fix issues in changed files
yarn lint-diff fix
After you've completed your main logic changes:
- Commit your local changes.
- Run yarn lint-diff fix. This will automatically fix formatting on all files you've modified compared to the main branch.
- Make a separate commit just for these formatting changes (label it clearly, like chore: prettier cleanup).
Bonus: Use It in CI
You can also add this to your CI pipeline to ensure only changed files meet your standards:
name: Lint and Format
on: [pull_request]
jobs:
lint-and-format:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Install dependencies
run: yarn install
- name: Fetch main branch
run: git fetch origin main
- name: Create changed_files.txt
run: git diff --name-only ${{ github.event.pull_request.base.sha }} --diff-filter=d -- 'apps/*.js' 'apps/*.ts' 'src/*.{js,ts,jsx,tsx}' > changed_files.txt
- name: Run lint and prettier on changed files
run: yarn lint-diff
This keeps your diffs focused and ensures each PR leaves the codebase just a little better than it was.
If you don’t want to write a custom script from scratch, there’s a handy alternative called pretty-quick. It’s a lightweight CLI tool that works with Prettier and formats only the files that have changed, either the staged ones using the --staged flag or files differing from a specific branch using the --branch flag. It’s particularly useful for integrating quick formatting checks in pre-commit hooks or CI workflows. You will need to install the package separately, though, since it doesn't come bundled with Prettier itself.
That said, pretty-quick is designed specifically for formatting and doesn’t handle linting. The custom script above allows you to cover both formatting and linting in one place. It also gives you more control and you can easily plug in additional tools like style linters or custom validation logic into your script.
Conclusion
Formatting and linting aren’t glamorous, but they’re essential. They protect your team’s time, reduce bugs, and make your code easier to understand and maintain.
If you’re starting a new project, set it up on day one. If you’re in the middle of a messy one, don’t panic. Just start small. Automate what you can. And make every PR a little cleaner than the last. Clean code shouldn’t be an afterthought. It should be your default. Because the worst kind of tech debt? It’s the one you saw coming and still let happen.
Just published
