Skip to Content
Course content

219: Formatting with Prettier

Click on the "Edit" button in the top corner of the screen to edit your slide content.

I once spent two hours debugging a production issue because a teammate had manually indented a block of code to look like it was inside an if statement, but they'd actually forgotten the curly braces. The code looked logically sound at a glance, but the JavaScript engine was executing it completely differently. It was a classic case of "visual lying."

// What it looked like in the editor
if (user.isAdmin)
    console.log("Admin access granted");
    grantSuperPermissions(user); // This looks like it's inside the if!

// What was actually happening
if (user.isAdmin) {
    console.log("Admin access granted");
}
grantSuperPermissions(user); // This runs for EVERYONE.

The High Cost of Manual Formatting

When you're working alone, you might have a "style" you like. But when you're on a team, or even just moving between different projects, manual formatting becomes a liability. You end up wasting mental energy on where the curly brace goes or whether to use single or double quotes. Worse yet, your Git diffs become a nightmare. I've seen pull requests with 50 "changes," but 48 of them were just someone changing tabs to spaces or adding trailing commas. It hides the actual logic changes and makes code reviews a chore.

Ending the Style Debate with Prettier

This is why we use Prettier. Unlike ESLint, which tells you that you're doing something wrong, Prettier just takes your code and reprints it from scratch according to a strict set of rules. It's "opinionated," meaning it doesn't give you a thousand toggles to argue about; it just decides how the code should look so you can stop thinking about it entirely.

To get this working, you usually install it via npm, but the real magic happens when you integrate it into your editor. I highly recommend enabling "Format on Save." There is a strange, meditative satisfaction in hitting Cmd+S (or Ctrl+S) and watching a chaotic mess of nested objects instantly snap into a clean, readable structure.

Defining Your Rules in .prettierrc

While Prettier is opinionated, there are a few things you'll probably want to standardize across your project. Instead of relying on editor settings—which vary from person to person—you create a .prettierrc file in your root directory. This file acts as the single source of truth for the whole team.

{
  "semi": true,
  "trailingComma": "es5",
  "singleQuote": true,
  "printWidth": 80,
  "tabWidth": 2
}

In this config, I'm telling Prettier to keep semicolons, use single quotes (which is the industry standard for JS), and wrap lines if they exceed 80 characters. Now, no matter who opens the project or what editor they use, the code will be formatted identically. No more "visual lies," and no more useless Git noise.




📋 Practical Task

Standardizing the Legacy API Wrapper

You've inherited a file called apiWrapper.js that was written by three different developers, each with their own formatting style. It's a mess of mixed quotes, inconsistent indentation, and missing semicolons, making it very hard to audit for security flaws.

Your Task:

  • Create a .prettierrc file that enforces single quotes, semicolons, and a tab width of 4.
  • Apply these formatting rules to the following code snippet to make it consistent and readable:
const apiConfig = {
  endpoint: "https://api.example.com/v1",
  timeout: 5000,
    headers: {
  "Content-Type": "application/json",
  "Authorization": 'Bearer token123'
    }
};

async function fetchData(url,options){
const response = await fetch(url,{
method:'GET',
...options
});
return response.json()
}
Rating
0 0

There are no comments for now.

to be the first to leave a comment.