Most developers install Prettier and hit save. But real control comes when you actually understand how it’s configured.

---

Introduction

If you’re a frontend developer, there’s a 99% chance you’ve heard of Prettier, the opinionated code formatter that “just makes code look nice.”

But here’s the thing:

Most developers never go beyond the defaults.

They install Prettier, turn on “Format on Save,” and think that’s it.

Meanwhile, their codebase still has random inconsistencies, mismatched quotes, weird line breaks, strange wrapping in JSX, and different rules between teammates.

That’s because Prettier only becomes powerful when you configure it properly.

In this guide, I’ll show you exactly how to:

• Understand Prettier’s opinionated core.
• Customize it for your team or stack (React, Node, Next.js, etc.)
• Integrate it with ESLint, Git hooks, and VS Code.
• Avoid the common “double-formatting” and conflict issues that plague teams

By the end, you’ll know how to tame Prettier, not just use it.

---

1. Why Configuration Matters

Out of the box, Prettier enforces a strict, consistent code style.
 But the defaults might not always match your project’s standards.

For example:

• Maybe your team prefers single quotes over double.
• Maybe you want no semicolons.
• Maybe you’re tired of Prettier wrapping JSX props onto new lines.

If you never configure it, Prettier will format your code its way, not your way.

The key to mastering Prettier is understanding the configuration layers and how to make them play nicely together.

---

2. The Prettier Philosophy

Before tweaking settings, understand one thing:

Prettier is opinionated by design.

That means it intentionally ignores personal preferences like “should I use 80 or 120 characters per line?” and “should if statements go on one line?”

Prettier’s job is to remove code style debates.

It has sensible defaults but gives you just enough flexibility to adapt to your project without turning into chaos.

---

3. The Configuration Hierarchy

Prettier looks for config in this order (from most specific to least):

1. CLI flags, e.g., npx prettier --write --single-quote true .
2. .prettierrc or .prettierrc.json – main config file
3. prettier.config.js – JS-based config (for comments or logic)
4. package.json → "prettier" key – inline config
5. Editor defaults (if no config found)

So if something “isn’t applying,” it’s probably being overridden at a higher level.

---

4. Create a Proper .prettierrc File

The .prettierrc The file is where you define all your preferences.
 Here’s a recommended base setup for JavaScript and TypeScript projects:

{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "useTabs": false,
  "printWidth": 100,
  "trailingComma": "es5",
  "bracketSpacing": true,
  "arrowParens": "always",
  "endOfLine": "lf"
}

What Each Option Means

💡 Tip: Keep this file in your project root and commit it to Git. That way, everyone formats code the same way automatically.

---

5. Using prettier.config.js for Complex Rules

If you want comments or conditional logic, you can use a JS-based config file instead:

// prettier.config.js
export default {
  semi: false,
  singleQuote: true,
  overrides: [
    {
      files: "*.json",
      options: {
        printWidth: 200
      }
    }
  ]
};

✅ This is especially useful when:

• You need different rules per file type
• You want to document decisions inline.
• You’re using ESM or TypeScript

---

6. Ignore Files You Don’t Want to Format

Prettier can sometimes mess up build files, generated code, or large JSON configs.

To exclude files, create a .prettierignore:

node_modules
dist
package-lock.json
coverage
.next
build

This works exactly like .gitignore Anything listed here will be skipped.

---

7. Configure VS Code the Right Way

Most developers install Prettier in VS Code but don’t configure it correctly, which leads to double-formatting or conflicts with the built-in formatter.

Here’s how to do it properly:

Step 1: Install the Prettier Extension

Search for Prettier Code Formatter in VS Code extensions.

Step 2: Update Your VS Code Settings

Open Command Palette → Preferences: Open Settings (JSON)
 Add these lines:

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "editor.formatOnSave": true,
  "[javascript]": { "editor.formatOnSave": true },
  "[typescript]": { "editor.formatOnSave": true },
  "prettier.requireConfig": true
}

✅ prettier.requireConfig Ensures Prettier only runs if a config file exists, so it doesn’t mess with random files.

---

8. Integrating with ESLint (Without Conflicts)

Many devs add Prettier + ESLint and immediately get errors like:

“Delete ␣ prettier/prettier”

That’s because both tools try to format your code.

To fix that, disable ESLint’s formatting rules and let Prettier handle formatting.

Step 1: Install the Prettier ESLint config

npm install --save-dev eslint-config-prettier eslint-plugin-prettier

Step 2: Update .eslintrc

{
  "extends": ["eslint:recommended", "plugin:prettier/recommended"],
  "plugins": ["prettier"],
  "rules": {
    "prettier/prettier": "error"
  }
}

Now, ESLint only checks for code quality, while Prettier handles style perfectly, separated.

---

9. Running Prettier Automatically (Git Hooks)

Even with Prettier installed, some developers forget to format before committing.

That’s why teams use Husky + Lint-Staged to run Prettier automatically before every commit.

Install Dependencies

npm install --save-dev husky lint-staged

Add to package.json

{
  "husky": {
    "hooks": {
      "pre-commit": "lint-staged"
    }
  },
  "lint-staged": {
    "*.{js,ts,jsx,tsx,css,scss,html,json,md}": "prettier --write"
  }
}

Now every time you commit, your staged files get formatted automatically.

💡 Result: No more messy commits. Your repo stays clean always.

---

10. Pro-Level Prettier Tips Most Developers Don’t Know

Here’s where that “1%” really stands out. These are small things that separate professionals from casual users.

1. Format Specific Files Only

npx prettier --write src/**/*.ts

2. Use Prettier --check in CI

npx prettier --check .

This verifies that all files follow your formatting rules, perfect for CI/CD pipelines.

3. Combine with eslint --fix

You can chain both in your package.json:

"scripts": {
  "lint": "eslint . --fix && prettier --write ."
}

4. Override Rules Per File

Inside .prettierrc:

{
  "overrides": [
    {
      "files": "*.md",
      "options": { "printWidth": 80 }
    }
  ]
}

5. Use EditorConfig for Global Consistency

If multiple tools edit your code (IDEA, Vim, VSCode), combine Prettier with .editorconfig for unified indentation rules.

---

11. Common Prettier Mistakes

Once you fix these, Prettier becomes invisible; it just works, silently keeping your codebase perfect.

---

12. Example: The Perfect Prettier Setup (for JS/React Projects)

Here’s a sample structure you can copy right now:

project-root/
│
├── .prettierrc
├── .prettierignore
├── .eslintrc
├── package.json
└── src/

.prettierrc

{
  "singleQuote": true,
  "semi": false,
  "trailingComma": "all",
  "printWidth": 100,
  "arrowParens": "always"
}

.prettierignore

node_modules
build
coverage
dist

package.json scripts

"scripts": {
  "format": "prettier --write .",
  "lint": "eslint . --fix && prettier --check ."
}

That’s it, a complete setup used by many production teams.

---

Conclusion

Most developers treat Prettier like a magic button: install, save, done.
But those who really understand how it works can tailor it to their workflow, enforce consistency across teams, and integrate it cleanly with linting and CI tools.

Prettier is more than a formatter; it’s a code consistency engine.

When configured properly, it becomes invisible. You never think about formatting again, and your codebase looks beautiful forever.

Pro Tip: Don’t stop at “install and save.” Create your .prettierrc, connect ESLint, add Husky, and you’ll join that elite 1% of developers who truly mastered Prettier.

---

Call to Action

What’s your Prettier setup like?
Share your configuration or workflow in the comments and bookmark this post for your next project setup.