JavaScript
Completed
-
Section 1: Getting Started
-
Section 2: Core Syntax and Types
-
Section 3: Strings and Numbers in Depth
-
Section 4: Control Flow
-
Section 5: Functions
-
Section 6: Objects and Arrays
-
Section 7: Maps, Sets, and Symbols
-
Section 8: Asynchronous JavaScript
-
Section 9: Object-Oriented and Prototypes
-
Section 10: The DOM
-
Section 11: Browser APIs
-
Section 12: Modern JavaScript (ES2015-ES2025)
-
Section 13: Functional Programming Patterns
-
Section 14: Error Handling and Debugging
-
Section 15: Testing
-
Section 16: Accessibility for JavaScript Developers
-
Section 17: Internationalization and Localization
-
Section 18: Performance
-
Section 19: Node.js Fundamentals
-
Section 20: Regular Expressions
-
Section 21: Design Patterns in JavaScript
-
Section 22: Security Basics
-
Section 23: Data Structures and Algorithms in JavaScript
-
Section 24: Practical Projects
-
Section 25: More Advanced Async Patterns
-
Section 26: More Object and Class Practice
-
Section 27: Working with Dates and Internationalization
-
Section 28: Web Components
-
Section 29: More DOM and Browser Practice
-
Section 30: Build Tooling for Vanilla JavaScript
-
Section 31: More Practice Projects
-
Section 32: Interview and Algorithm Practice
-
Section 33: Error Objects (MDN Reference)
-
Section 34: TypedArrays and Binary Data
-
Section 35: Reflection and Metaprogramming (MDN Reference)
-
Section 36: More Global Functions (MDN Reference)
219: Formatting with Prettier
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
.prettierrcfile 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()
}There are no comments for now.