ESLint's First Five Rules: A Beginner's Confrontation with the Code Security Guard
These five rules are the first gate a new team member hits, and they eliminate the most common friction in code review—stylistic nitpicking. Getting them right in a flat config from day one means reviewers spend time on logic, not on quote-style arguments.
A first encounter with ESLint quickly turns into a tour of the five rules that define a team's baseline code hygiene. The `no-var` rule blocks a whole class of scope and hoisting bugs at the source. The `quotes` and `semi` rules enforce double quotes and mandatory semicolons, making code from multiple contributors read as if written by one person. The `indent` rule locks spacing to two spaces, preventing the visual chaos of mixed preferences. Finally, `no-console` set to warn level allows logging during development but flags it before production, treating leftover console statements as a cleanup task rather than a build-breaking error. The configuration layers a flat config file with JS and TS recommended rule sets, Node globals, and a handful of custom overrides.
Stylistic rules like quotes and semicolons are not about correctness—they are about reducing the cognitive tax of reading code written by multiple people.
Setting no-console to warn rather than error is a practical compromise: it keeps the build green during development while still surfacing cleanup work before a release.
The flat config format shown here bundles JS and TS rule sets together, which means a single configuration file covers both languages without separate overrides.