Just started a greenfield TypeScript app and the linter landscape feels more crowded than a dashboard with too many KPIs 😅. ESLint is the obvious base, but the plugin/config combos are overwhelming.
What's the pragmatic choice these days for a balanced, "sensible defaults" setup? I'm looking at:
* **`typescript-eslint`** – The standard, but do I need all the strict rules from the start?
* **Prettier integration** – Do you run them separately or use `eslint-config-prettier`?
* **Accessibility (jsx-a11y)** – Is it a must-have from day one for a web app?
* **Import sorting** – Worth the hassle for a small team?
I care less about absolute strictness and more about catching real bugs and keeping the codebase consistent as the team grows. What's your go-to `.eslintrc.js` for a new project in 2024? Bonus points if it plays nice with VS Code's auto-fix on save.
data over opinions
Forget half those plugins. `typescript-eslint` with the strict ruleset is your actual bug catcher. The rest is decoration that bogs down CI.
Skip import sorting, it's a time sink for tiny gains. Prettier separately, always. The integration configs just add friction when you eventually tweak something.
And jsx-a11y on day one? Only if you want your team to start hating the linter by week two. Add it later when you're ready to actually fix the violations, not just noise-up the console.
null
I mostly agree, but skipping import sorting is a mistake for a team that plans to grow. It's a trivial auto-fix that eliminates pointless merge noise and "why is my import line different" debates. It's not about the sorting, it's about removing a whole category of meaningless diff.
You're dead right about jsx-a11y though. Throwing 50 new errors at a team trying to build an MVP is how you breed "npm run lint -- --no-verify" habits. Enable it when you can dedicate a sprint to cleaning up the baseline.
The one thing I'd tweak is "Prettier separately, always." I've found the integration works fine if you set it up once and forget it. The real friction is when someone's editor isn't formatting on save and they don't know which tool is complaining.
garbage in, garbage out
You've got the right priorities - catching bugs and maintaining consistency for a growing team. Starting with the `typescript-eslint` recommended config gives you that sensible baseline without the fatigue of all strict rules from day one.
For your VS Code setup, I'd suggest enabling "editor.codeActionsOnSave" with "source.fixAll.eslint" and letting Prettier handle formatting separately. That combo usually works without the integration configs causing confusion, especially when new team members join.
The import sorting debate in the thread is interesting - it's less about the order itself and more about eliminating a source of trivial merge conflicts. For a greenfield project, adding something like `eslint-plugin-import` with auto-fix on save might be a low-friction way to avoid those early team debates.
—HR