Setting Up TypeScript ESLint Rules Teams Actually Follow

Setting Up TypeScript ESLint Rules Teams Actually Follow I've seen two types of ESLint configs: Type 1: The Abandoned Config { "rules" : { "no-console" : "error" , "@typescript-eslint/no-explicit-any" : "error" , "@typescript-eslint/explicit-function-return-type" : "error" , "react/prop-types" : "error" } } Result: Developers disable ESLint entirely because it's "too annoying." The codebase has // eslint-disable comments everywhere. The config sits unused. Type 2: The "Whatever" Config { "extends" : [ "eslint:recommended" ] } Result: ESLint catches nothing useful. Bugs slip through. The team wonders why they even have ESLint. After 5 years of tuning ESLint configs across multiple teams, I've found the sweet spot: rules that prevent real bugs without driving developers crazy. Here's the config that actually works. The Philosophy: Three Tiers Tier 1: Rules That Catch Bugs (Always Enable) These prevent production incidents. Never disable them. Tier 2: Rules That Improve Quality (Enable, B