I Just Discovered Prettier and Husky and Now I’m Wondering Why I Didn’t Start Earlier!

Image by author

A few days ago, I added prettier and Husky to my workflow.

Now I’m looking at my older projects and asking myself: why wasn’t I doing this from day one?

If you’re working on a *Javascript/Typescript* codebase especially with a team this setup is not a “nice to have” it’s foundational.

Lets break it down.

The Problem: Inconsistent Code in Team Projects

When multiple developers work on the same repository, formatting becomes a silent source of friction:

• Different quote styles (‘’ vs “”)
• Random spacing and line breaks
• Unsorted imports
• No consistent wrapping rules

None of this affects functionality, but it destroys readability and pollutes pull requests with meaningless diffs.

You end up reviewing formatting instead of logic.

That’s wasted time.

Prettier: Enforcing a Single Source of Formatting Truth

Prettier is a lightweight code formatter that automatically formats your code based on rules you define.

You configure it once using a prettierrc.json file:

{
  "semi": true,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2,
  "useTabs": false,
  "arrowParens": "always",
  "endOfLine": "lf",
  "plugins": [
    "@trivago/prettier-plugin-sort-imports",
    "prettier-plugin-tailwindcss"
  ],
  "importOrder": [
    "^react",
    "^next",
    "<THIRD_PARTY_MODULES>",
    "^@repo/(.*)$",
    "^@/(.*)$",
    "^[./]"
  ],
  "importOrderSeparation": true,
  "importOrderSortSpecifiers": true,
  "importOrderGroupNamespaceSpecifiers": true,
  "importOrderCaseInsensitive": true
}

Now you are entire project has one formatting standard.

To check whether your code follows those rules. you run:

pnpm prettier --check

If something doesn’t match, Prettier tells you.

To fix everything automatically:

pnpm prettier --write .

This eliminates style debates and keeps the codebase clean.

Why Manual Formatting Isn’t Enough

Here’s the reality:

Even if your team agrees to run Prettier before pushing, people forget.

Not because they don’t care but because it’s an extra step in a busy workflow.

That’s where automation becomes critical.

Husky: Automating Formatting at Commit Time

Husky lets you run scripts automatically during Git hooks.

Once installed and initialized, it creates a .husky folder in your project root.

Inside it, you can configure a pre-commit hook.

Example:

pnpm add -D husky
pnpm husky init

Then edit .husky/pre-commit :

pnpm prettier --check .
pnpm prettier --write .

Now every time you commit:

• Prettier checks your code
• Fixes formatting if needed
• Prevents inconsistent code from entering the repo

No manual steps. No forgotten commands.

The Real Benefits

This setup gives you:

• consistent formatting across the entire codebase
• cleaner pull requests (only logic changes show up)
• Faster code reviews
• Zero formatting arguments in the team
• Better long term maintainability

It also makes onboarding new developers easier they don’t need to learn your style.

The tooling enforces it.

What I’d Do Differently From Day One

If I were starting a new project today, this would be my default setup:

• Install Prettier
• Define formatting rules
• Add Husky with a pre-commit hook
• (Optional but recommended) add lint-staged to run only on staged files for faster commits

Formatting would never be a discussion again.

Final Thoughts

Prettier keeps your code consistent.

Husky makes that consistency automatic.

Together, they remove an entire class of problems from your development process.

This isn’t about making code “look pretty.”

it’s about making teams faster, reviews cleaner, and codebases easier to maintain.

If your repo doesn’t have this yet, add it today.

I share short, practical setups like this Prettier, monorepo’s, CI pipelines, payment infra, and DX systems that save real hours in production.

One email. No noise. Only when there’s something worth shipping.

Subscribe here: https://nikhilsai.in/newsletter