Lesson 2 of 49 beginner

Developer Tooling

Work Smarter, Not Harder

Open interactive version (quiz + challenge)

Real-world analogy

A carpenter without tools just has wood and hands. Developer tools are like power tools — ESLint is the level (keeps things straight), Prettier is the sander (makes it smooth), and Husky is the quality inspector who checks BEFORE you ship!

What is it?

Developer tooling includes linters (ESLint), formatters (Prettier), git hooks (Husky), and editor extensions that automate code quality. They catch bugs, enforce style, and prevent bad code from being committed.

Real-world relevance

Every professional development team uses these tools. They're the difference between 'weekend project' and 'production-ready codebase'. Set them up once, benefit forever.

Key points

Code example

// 1. ESLint — catch bugs automatically 🐛
// .eslintrc.js (legacy format — ESLint 9+ uses eslint.config.js)
module.exports = {
  parser: '@typescript-eslint/parser',
  plugins: ['@typescript-eslint'],
  extends: [
    'eslint:recommended',
    'plugin:@typescript-eslint/recommended',
  ],
  rules: {
    'no-unused-vars': 'error',      // Unused variables? Error!
    'no-console': 'warn',           // console.log? Warning!
    '@typescript-eslint/no-explicit-any': 'error', // Using 'any'? Error!
  },
};

// 2. Prettier — consistent formatting 🎨
// .prettierrc
{
  "semi": true,
  "singleQuote": true,
  "tabWidth": 2,
  "trailingComma": "all",
  "printWidth": 80
}

// 3. Husky — git hooks (runs before commit) 🐕
// package.json
{
  "scripts": {
    "prepare": "husky"
  },
  "lint-staged": {
    "*.{ts,tsx}": ["eslint --fix", "prettier --write"],
    "*.{json,md}": ["prettier --write"]
  }
}

// .husky/pre-commit
#!/bin/sh
npx lint-staged
# If ESLint finds errors → commit is BLOCKED! 🚫

Line-by-line walkthrough

  1. 1. Comment: ESLint catches bugs automatically
  2. 2. Comment: ESLint configuration file name
  3. 3. Exporting the ESLint config as a module
  4. 4. Setting the parser to understand TypeScript syntax
  5. 5. Specifying TypeScript ESLint plugins to use
  6. 6. Opening the 'extends' array for preset rule collections
  7. 7. Using ESLint's recommended built-in rules
  8. 8. Adding TypeScript-specific recommended rules
  9. 9. Closing the extends array
  10. 10. Opening custom rules section
  11. 11. Unused variables cause an error - helps keep code clean
  12. 12. console.log triggers a warning - reminds you to remove debug logs
  13. 13. Using TypeScript 'any' type causes an error - forces proper types
  14. 14. Closing the rules section
  15. 15. Closing the config export
  16. 16.
  17. 17. Comment: Prettier formats code consistently
  18. 18. Comment: Prettier configuration file name
  19. 19. Opening the Prettier config object
  20. 20. Always add semicolons at end of statements
  21. 21. Use single quotes instead of double quotes
  22. 22. Use 2 spaces for indentation
  23. 23. Add trailing commas (helps with git diffs)
  24. 24. Wrap lines longer than 80 characters
  25. 25. Closing the Prettier config
  26. 26.
  27. 27. Comment: Husky runs checks before git commits
  28. 28. Comment: package.json configuration
  29. 29. Opening the package.json section
  30. 30. Opening the scripts section
  31. 31. The 'prepare' script sets up Husky hooks on npm install
  32. 32. Closing scripts
  33. 33. Opening lint-staged config - only checks files being committed
  34. 34. For TypeScript files: auto-fix ESLint, then auto-format with Prettier
  35. 35. For JSON and Markdown: just auto-format with Prettier
  36. 36. Closing lint-staged config
  37. 37. Closing the package.json section
  38. 38.
  39. 39. Comment: The actual Husky pre-commit hook file
  40. 40. Shebang line telling the system to use sh shell
  41. 41. Run lint-staged via npx when a commit is attempted
  42. 42. Comment: If ESLint finds errors, the commit is blocked!

Spot the bug

// .eslintrc.js
module.exports = {
  rules: {
    'no-unused-vars': 'warning',
  },
};
Need a hint?
ESLint rule severity levels have specific allowed string values...
Show answer
The value 'warning' is not a valid ESLint severity. Valid values are 'off', 'warn', or 'error' (or 0, 1, 2). Fix: change 'warning' to 'warn'.

Explain like I'm 5

Imagine your room is messy and you have to clean it yourself every day. Developer tools are like having a robot that tidies up automatically! ESLint spots things in the wrong place, Prettier makes everything neat, and Husky checks your room before you leave the house.

Fun fact

The 'tabs vs spaces' debate has been going on since the 1960s. Prettier ended it by saying 'I don't care what you prefer, I'll format it MY way.' And everyone agreed because they were tired of arguing! 😂

Hands-on challenge

Add ESLint + Prettier + Husky to a project. Make a deliberate formatting mistake, try to commit — watch Husky block it! Then fix it and commit successfully.

More resources

Open interactive version (quiz + challenge) ← Back to course: Full-Stack Playbook