FE7: The modern frontend toolkit
Linting, formatting and code checks
🎯You'll be able to
Set up linting and formatting so code checks run the same for everyone.
🏠The everyday picture
A newspaper's sub-editor checks spelling, house style and facts before print, so the writer can focus on the story. Linters and formatters are automatic sub-editors for code.
📘What it really is
-
Formatter (Prettier): decides spacing, quotes and line breaks automatically, so code looks the same whoever wrote it and reviews focus on meaning.
-
Linter (ESLint): finds likely bugs and risky patterns. Useful rule sets for frontend:
- react-hooks: hooks called in the right order, effect dependencies listed;
- jsx-a11y: missing alt text, clickable divs, missing labels (FE6);
-
TypeScript rules: no
any, no unused variables, no floating promises. -
Type check:
tsc --noEmitchecks types across the project. - Run them:
- in the editor, as you type;
- before commit, with a pre-commit hook on changed files;
-
in CI on every pull request (FE9), so nothing merges with errors.
-
Start strict on new projects. On old projects, turn rules on gradually and fix as you touch files, rather than one giant change.
📝A worked example
Adding the react-hooks and jsx-a11y rules to Kirana's codebase:
| Rule | Findings | Example |
|---|---|---|
react-hooks/exhaustive-deps |
11 | Store picker effect missing storeId in its dependencies |
jsx-a11y/alt-text |
7 | Category images without alt |
jsx-a11y/click-events-have-key-events |
4 | Clickable divs |
@typescript-eslint/no-explicit-any |
19 | API helpers |
The missing dependency explained a long-standing bug where stock sometimes showed for the previous store.
🌍Where it's used
- Every team codebase.
- Open-source projects with many contributors.
- Code review, freeing reviewers to discuss design rather than spacing.
📝Case scenario
Every pull request in a team has dozens of comments about spacing and quote style, and arguments slow merges. Adding Prettier with a shared config, formatting the codebase once in a single commit, and checking formatting in CI ends the debate. Reviews get shorter and more useful.
🖱️Try it
Add Prettier, ESLint with the react-hooks and jsx-a11y rules, and a type check to your Kirana project. Set up a pre-commit hook for changed files, then fix everything the tools report and note the most surprising finding.
⚠️Common mistakes
- Turning off a rule instead of fixing the code. Sign: many disable comments. Fix: fix the cause; disable only with a written reason.
- Formatting arguments in reviews. Sign: review comments about spaces. Fix: let the formatter decide and run it before each commit.
🛠️For your project
Add a lint check to your Project 2 work and include its result in your evidence.
✅Quick check
What's the difference between a formatter and a linter?
Show the answer
A formatter fixes how code looks; a linter finds likely bugs and risky patterns.
How should you add strict lint rules to a large old codebase?
Show the answer
Gradually, fixing files as they're touched, rather than in one huge change.