Linting
| Lint beyond types | |
| ESLint with typescript-eslint | |
| Rules that matter | |
| Type-aware rules need a project |
Lint beyond types
The compiler proves types line up, but it stays silent about dead code, floating promises, and confusing style. A linter reads intent and flags patterns that often hide bugs.
Treat the two tools as partners. Types guard the contracts, lint guards the habits that keep code readable.
let discount = 0.2;
discount = 0.25;
console.log(discount);
ESLint with typescript-eslint
ESLint is the standard JavaScript linter, and the typescript-eslint project adds TypeScript aware parsing and rules on top of it. The command below is shown as text only so you can recognize it in docs.
Setup varies by project layout, so follow the typescript-eslint docs for your setup. No install step is shown here.
npx eslint .
lint report with warnings and errors
Rules that matter
Start with a small set that prevents real bugs: no unused variables, no unsafe any leaks, and no forgotten await on promises. A short list that the team respects beats a long list that everyone ignores.
Add one rule at a time and fix the whole codebase before adding the next. Green builds stay green while standards rise step by step.
async function loadUser(id: number): Promise<string> {
return fetchName(id);
}
Type-aware rules need a project
The most valuable rules ask the type checker for facts, such as whether a value may be null at this exact line. Those rules need the project config so the linter can load full type information.
Point the linter at tsconfig.json once. From then on it reasons with types, not just syntax, and its reports read like compiler errors with style advice.
tsc --noEmit
types are clean, lint can focus on style
Next: Formatting
Article author: Arthur Isaev