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
- ESLint — ESLint is a static analysis tool that scans your JavaScript and TypeScript code for bugs, bad patterns, and style violations without running it. Configure rules like 'no unused variables' or 'no implicit any' and ESLint flags every violation instantly in your editor with red underlines.
- Prettier — Prettier is an opinionated code formatter that automatically restructures your code to follow consistent style rules — indentation, quotes, semicolons, line width. Run it on save and your entire team's code looks identical, eliminating all formatting debates and messy pull request diffs forever.
- Husky + lint-staged — Husky installs Git hooks that run scripts automatically before commits or pushes. Combined with lint-staged, it runs ESLint and Prettier ONLY on the files you changed — catching issues before they enter your codebase without slowing down your workflow on every commit.
- VS Code Extensions — Extensions like Tailwind IntelliSense (autocomplete CSS classes), Prisma (schema highlighting), ESLint (inline error markers), and GitLens (blame annotations) transform VS Code from a basic text editor into a fully integrated development environment tailored to your stack.
- Git Hooks — Git hooks are scripts that run automatically on git events like pre-commit, pre-push, and post-merge. They enforce quality gates — blocking a commit if tests fail or linting errors exist. They act as automated checkpoints that prevent broken code from ever reaching your repository.
- Debugging with Node Inspector — Use node --inspect to start a debugging session. Set breakpoints in VS Code, step through code line by line, inspect variables in real-time. Much more powerful than console.log — like using a magnifying glass instead of squinting at your screen.
- EditorConfig & Workspace Settings — An .editorconfig file ensures consistent editor settings (indent size, line endings, charset) across different editors and IDEs. Paired with VS Code workspace settings in .vscode/settings.json, every developer on your team gets identical editor behavior automatically from day one.
- Package Scripts & Task Runners — The scripts section in package.json defines reusable commands: npm run dev starts your server, npm run build compiles production code, npm run test runs your test suite. Well-organized scripts replace memorizing long CLI commands with simple, shareable shortcuts that anyone on your team can use.
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. Comment: ESLint catches bugs automatically
- 2. Comment: ESLint configuration file name
- 3. Exporting the ESLint config as a module
- 4. Setting the parser to understand TypeScript syntax
- 5. Specifying TypeScript ESLint plugins to use
- 6. Opening the 'extends' array for preset rule collections
- 7. Using ESLint's recommended built-in rules
- 8. Adding TypeScript-specific recommended rules
- 9. Closing the extends array
- 10. Opening custom rules section
- 11. Unused variables cause an error - helps keep code clean
- 12. console.log triggers a warning - reminds you to remove debug logs
- 13. Using TypeScript 'any' type causes an error - forces proper types
- 14. Closing the rules section
- 15. Closing the config export
- 16.
- 17. Comment: Prettier formats code consistently
- 18. Comment: Prettier configuration file name
- 19. Opening the Prettier config object
- 20. Always add semicolons at end of statements
- 21. Use single quotes instead of double quotes
- 22. Use 2 spaces for indentation
- 23. Add trailing commas (helps with git diffs)
- 24. Wrap lines longer than 80 characters
- 25. Closing the Prettier config
- 26.
- 27. Comment: Husky runs checks before git commits
- 28. Comment: package.json configuration
- 29. Opening the package.json section
- 30. Opening the scripts section
- 31. The 'prepare' script sets up Husky hooks on npm install
- 32. Closing scripts
- 33. Opening lint-staged config - only checks files being committed
- 34. For TypeScript files: auto-fix ESLint, then auto-format with Prettier
- 35. For JSON and Markdown: just auto-format with Prettier
- 36. Closing lint-staged config
- 37. Closing the package.json section
- 38.
- 39. Comment: The actual Husky pre-commit hook file
- 40. Shebang line telling the system to use sh shell
- 41. Run lint-staged via npx when a commit is attempted
- 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
- ESLint Getting Started (ESLint Official)
- Prettier Documentation (Prettier Official)
- ESLint & Prettier Setup (Traversy Media)