Why I stopped using Prettier's default configuration

I used Prettier's default configuration for years. It was the path of least resistance -- install it, run it, and never think about code formatting again. The defaults work fine for most projects, and the "no configuration" philosophy meant one less thing to bikeshed with my team. Then I started working on a large TypeScript codebase with complex object destructuring and long import statements, and I realized Prettier's defaults were actually hurting my productivity.

The breaking point came when I was reviewing a pull request with a 200-line diff that was mostly Prettier reformatting import statements. A teammate had added a single import, but Prettier's 80-character print width caused a cascade of line breaks across dozens of files. The actual code change was buried in formatting noise, making the review much harder than it needed to be.

That's when I learned that Prettier's opinionated defaults are not always the right opinion for every codebase. A few strategic configuration changes dramatically improved my code readability and Git diff quality.

The Default Configuration Problems

Here's what frustrated me most about Prettier's defaults:

// Prettier default: 80 character print width
import {
  UserProfile,
  UserSettings,
  UserPreferences,
  UserNotifications
} from './types/user';
 
// What I wanted: 120 characters
import { UserProfile, UserSettings, UserPreferences, UserNotifications } from './types/user';

The 80-character limit made sense in the era of terminal windows, but modern editors handle longer lines just fine. More importantly, the constant line wrapping was creating unnecessary Git conflicts when multiple people worked on the same files.

Another pain point was trailing commas in function parameters:

// Prettier default: no trailing comma in function parameters
function createUser(
  name: string,
  email: string,
  role: string
) {
  // implementation
}
 
// What I wanted: consistent trailing commas everywhere
function createUser(
  name: string,
  email: string,
  role: string,
) {
  // implementation
}

Inconsistent trailing comma rules meant that adding a parameter sometimes required changing two lines instead of one, creating messier diffs.

My Custom Configuration

After experimenting with different settings across several projects, I settled on this configuration:

{
  "printWidth": 120,
  "tabWidth": 2,
  "useTabs": false,
  "semi": true,
  "singleQuote": true,
  "quoteProps": "as-needed",
  "trailingComma": "all",
  "bracketSpacing": true,
  "arrowParens": "avoid"
}

The key changes from defaults:

• printWidth: 120 -- Reduces unnecessary line wrapping without creating unreadably long lines
• singleQuote: true -- Consistent with most JavaScript style guides and requires fewer escape characters
• trailingComma: "all" -- Makes adding/removing items cleaner in Git diffs
• arrowParens: "avoid" -- Cleaner syntax for single-parameter arrow functions

Real-World Impact

These changes had immediate benefits in my daily workflow:

Fewer Git conflicts: Longer print width meant fewer cascading reformats when imports changed. Our team's merge conflicts dropped by about 30% after making this change.

Cleaner diffs: Trailing commas everywhere meant adding array items or object properties only changed one line instead of two. Code reviews became much easier to follow.

Better readability: Single quotes and minimal arrow function parentheses reduced visual noise, especially in React components with lots of inline handlers.

Consistent style across tools: Most ESLint configurations and TypeScript examples use single quotes and trailing commas, so my Prettier config now aligns with the broader ecosystem.

The Configuration Process

I did not change everything at once. Instead, I:

1. Started with print width -- this had the biggest impact on day-to-day frustration
2. Added trailing commas after seeing how much cleaner the Git diffs became
3. Switched to single quotes to match our ESLint rules
4. Fine-tuned the remaining options based on team feedback

The key was measuring the impact of each change on actual code reviews and Git operations, not just personal preference.

When to Stick with Defaults

Prettier's defaults are still the right choice for many situations:

• New teams that want to avoid configuration bikeshedding
• Open source projects that need to follow community standards
• Small codebases where the benefits are not worth the setup time
• Teams with mixed editor preferences where longer lines might cause problems

But if you're working on a larger codebase or finding that Prettier's formatting is creating friction in your workflow, it's worth experimenting with a few targeted configuration changes.

The goal is not to completely override Prettier's opinions, but to fine-tune them for your specific context. A few strategic tweaks can make a significant difference in code readability and development experience without sacrificing the core benefits of automated formatting.