How I Configure Prettier for Modern JavaScript in 2025

I spent three hours last Tuesday debugging a merge conflict that shouldn’t have existed. Two developers on my team had slightly different VS Code settings—one was using a trailing comma, the other wasn’t. It sounds trivial, but in a massive diff, those little syntax noises hide the actual logic changes. That wasted afternoon reminded me exactly why I force strict formatting rules on every project I touch. It’s not just about aesthetics; it’s about preserving sanity.

With the recent waves of JavaScript Prettier News highlighting better plugin support and faster parsing engines, I decided it was time to audit my default configuration. I’ve been relying on the same .prettierrc file since 2023, and frankly, it was starting to show its age. The ecosystem has moved on. We have new JavaScript features, new frameworks, and new expectations for how tooling should behave.

Why I’m Still Betting on Prettier in 2025

There was a moment last year when I considered switching to one of those all-in-one Rust-based toolchains. They promised speed, and for a while, I was seduced by the idea of sub-millisecond linting. But I came back. Why? Because the ecosystem around Prettier is just too rich to ignore. The plugin architecture allows me to format everything from SQL to Nginx configs, not just my JavaScript and TypeScript files.

The latest updates have significantly improved how Prettier handles experimental syntax. I remember the pain of waiting for support for decorators or top-level await. Now, the parser seems to be in lockstep with the TC39 proposals. When I read JavaScript TypeScript News, I don’t worry about my formatter breaking on new syntax anymore.

Setting Up the Modern Config

I’ve stopped using JSON for configuration. It’s 2025; we should be using ESM for everything. Using a prettier.config.js file gives me type safety via JSDoc and allows me to dynamically construct rules if I need to (though I rarely do). Here is the baseline config I drop into every new repository now.

/** @type {import("prettier").Config} */
const config = {
  semi: false,
  singleQuote: true,
  tabWidth: 2,
  trailingComma: 'all',
  printWidth: 100,
  arrowParens: 'always',
  endOfLine: 'lf',
  // The new plugin loading strategy is much cleaner now
  plugins: ['prettier-plugin-tailwindcss'],
};

export default config;

I prefer semi: false. I know this is a religious debate for some, but I find the code looks cleaner without the visual noise. The automatic semicolon insertion in JavaScript is robust enough that I haven’t run into a Zalgo-related issue in years.

Handling Complex Async Workflows

One place where formatting really matters is in complex asynchronous logic. When you have nested try/catch blocks inside async functions, bad formatting makes the control flow impossible to track. I recently refactored a data ingestion script for a JavaScript Node.js News aggregator I’m building, and Prettier saved me from a callback hell situation.

Here is how I structure my async handlers now, relying on Prettier to keep the indentation logic clear:

async function fetchAndProcessUserMetrics(userId) {
  if (!userId) {
    throw new Error('User ID is required for metrics processing');
  }

  try {
    // Prettier keeps these chained calls readable
    const userProfile = await database
      .collection('users')
      .findOne({ id: userId })
      .select('settings preferences history')
      .lean();

    if (!userProfile) {
      return null;
    }

    const metrics = await calculateMetrics(userProfile);
    
    // I love how it breaks long arguments into multiple lines automatically
    await notificationService.sendSummaryEmail(
      userProfile.email,
      'Weekly Metrics Report',
      metrics,
      { priority: 'high', trackOpen: true }
    );

    return metrics;
  } catch (error) {
    logger.error(Failed to process metrics for user ${userId}, {
      originalError: error.message,
      stack: error.stack,
    });
    throw error;
  }
}

Notice how the database chain is aligned. Before I locked down my config, I would see developers merge this into one massive 140-character line. Now, Prettier forces the break, making it obvious what methods are being chained.

DOM Manipulation and Event Listeners

While I do a lot of React and Vue work (keeping up with JavaScript React News is a full-time job), I still write plenty of vanilla JS for lightweight interactions. Formatting DOM code can get messy because of the verbose method names. document.querySelector isn’t exactly short.

I found that increasing the printWidth to 100 (up from the default 80) helps significantly with DOM-heavy code. It prevents premature wrapping on simple event listener attachments.

function initializeNavigation() {
  const navToggle = document.querySelector('[data-test-id="nav-toggle"]');
  const sidebar = document.getElementById('main-sidebar');
  const overlay = document.querySelector('.overlay-backdrop');

  if (!navToggle || !sidebar) return;

  // Clean formatting for event handlers
  navToggle.addEventListener('click', (event) => {
    event.preventDefault();
    const isExpanded = navToggle.getAttribute('aria-expanded') === 'true';
    
    navToggle.setAttribute('aria-expanded', !isExpanded);
    sidebar.classList.toggle('visible');
    
    if (overlay) {
      overlay.classList.toggle('active');
    }
  });

  // Handling resize with a debounce
  window.addEventListener(
    'resize',
    debounce(() => {
      if (window.innerWidth > 1024) {
        sidebar.classList.remove('visible');
        navToggle.setAttribute('aria-expanded', 'false');
      }
    }, 200)
  );
}

The indentation inside the addEventListener callback is crucial. Without strict formatting, I often see the closing parenthesis ); dangling in weird places or getting lost entirely. Prettier enforces a consistent structure that my eyes can scan instantly.

API Interaction and Large Objects

Another area where I’ve tightened my rules is around API calls. When constructing large request bodies or handling complex JSON responses, manual formatting is a waste of time. I see so many junior developers manually hitting the spacebar to align keys in an object. It drives me crazy. Just let the tool do it.

I’m currently working on an integration that requires sending a massive payload to a third-party CRM. Here is how Prettier handles the object construction, ensuring the keys are readable:

async function syncContactToCrm(contactData) {
  const endpoint = 'https://api.crm-provider.com/v3/contacts/upsert';
  
  const payload = {
    properties: {
      firstname: contactData.firstName,
      lastname: contactData.lastName,
      email: contactData.email,
      website: contactData.website,
      company: contactData.companyName,
      // Prettier handles comments inside objects perfectly
      lifecyclestage: 'marketingqualifiedlead', 
      phone: contactData.phone,
      address: contactData.address.street,
      city: contactData.address.city,
      zip: contactData.address.zipCode,
    },
    options: {
      updateExisting: true,
      triggerWorkflows: false,
    },
  };

  const response = await fetch(endpoint, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json',
      'Authorization': Bearer ${process.env.CRM_API_KEY},
    },
    body: JSON.stringify(payload),
  });

  if (!response.ok) {
    const errorData = await response.json();
    throw new Error(CRM Sync Failed: ${errorData.message});
  }

  return response.json();
}

The beauty here is the trailingComma: 'all' setting. If I need to add a new field to the properties object later, I can duplicate the last line and modify it without touching the previous line’s comma. It makes git diffs much cleaner. I used to hate trailing commas, but after reviewing thousands of PRs, I consider them essential.

Integration with ESLint Flat Config

The biggest shift in JavaScript ESLint News recently has been the total adoption of Flat Config. For a long time, making Prettier and ESLint play nice was a headache involving eslint-config-prettier and potential rule conflicts. In 2025, this is much smoother.

I now treat Prettier strictly as a formatter and ESLint strictly as a linter. I don’t run Prettier inside ESLint anymore (that used to be slow). Instead, I run them as separate steps in my CI pipeline. This separation of concerns has sped up my linting process by about 40%.

My workflow looks like this:

1. Editor: Runs Prettier on save. Immediate feedback.
2. Git Hook (Husky): Runs prettier --write on staged files. Prevents bad commits.
3. CI Pipeline: Runs prettier --check. Fails the build if formatting is off.

This redundancy ensures that no matter what editor a contractor or new hire is using, the code that hits the repository conforms to the standard. I’ve seen too many teams relax these rules only to end up with a codebase that looks like a ransom note—mixed quotes, varying indentation, and chaotic brackets.

The Framework Specifics

When working across different frameworks, Prettier’s adaptability shines. In my JavaScript Svelte News reading, I noticed how seamless the Svelte plugin has become. It formats the script, markup, and style tags within a .svelte file with distinct rules, respecting the context of each section.

Similarly, for JavaScript Vue.js News enthusiasts, the handling of the <template> section has improved. It no longer aggressively wraps attributes unless absolutely necessary, which keeps the HTML structure readable. I use the same config for my Next.js projects (relevant to JavaScript Next.js News) as I do for my backend NestJS services.

Here is a quick example of how I handle component props formatting in React, which often gets messy:

const UserCard = ({ user, onEdit, onDelete, isAdmin }) => {
  return (
    <div className="p-4 border rounded-lg shadow-sm hover:shadow-md transition-shadow">
      <div className="flex justify-between items-center mb-4">
        <h3 className="text-lg font-bold text-gray-800">
          {user.firstName} {user.lastName}
        </h3>
        {isAdmin && (
          <span className="px-2 py-1 text-xs bg-blue-100 text-blue-800 rounded">
            Admin
          </span>
        )}
      </div>
      
      <div className="flex gap-2 mt-4">
        <button 
          onClick={() => onEdit(user.id)}
          className="px-4 py-2 text-sm text-white bg-indigo-600 rounded hover:bg-indigo-700"
        >
          Edit Profile
        </button>
        
        {/* Prettier handles these multiline conditionals gracefully */}
        {isAdmin && !user.isProtected && (
          <button 
            onClick={() => onDelete(user.id)}
            className="px-4 py-2 text-sm text-red-600 border border-red-200 rounded hover:bg-red-50"
          >
            Delete User
          </button>
        )}
      </div>
    </div>
  );
};

Without Prettier, those conditional rendering blocks often end up impossible to read. The auto-formatting ensures that the logical hierarchy of the JSX matches the visual hierarchy of the code.

Final Thoughts on Tooling

It is easy to get distracted by the shiny new toys in the JavaScript Bun News or JavaScript Deno News feeds. But reliable tooling is boring. It should be boring. I don’t want my formatter to be “exciting”; I want it to be invisible.

The recent updates to Prettier have reinforced its position as the default choice for a reason. It just works. It handles the edge cases, it supports the new syntax from JavaScript Babel News, and it integrates with every editor on the planet. If you haven’t updated your config in a few years, take ten minutes today to do it. Enable strict plugins, switch to ESM configuration, and turn on trailing commas. Your future self (and your team) will thank you when the git diffs are clean and the merge conflicts are gone.