Been using ESLint for a year now on my team's main JS project. We needed consistency, everyone was formatting code differently.
But honestly? The setup was a massive time sink. Picking plugins, arguing over rules, maintaining the config file. Felt like we spent more time configuring the linter than actually fixing the problems it found.
For a new solo project, I'm questioning if it's worth it. The "free" tool cost us a lot in dev hours upfront. Does the pay-off over time actually balance that out? Or are there simpler, good-enough alternatives that don't need a PhD to set up?
I'm a lead engineer at a 200-person B2B SaaS company, and we've used ESLint across our TypeScript frontends and Node.js backends for about three years now.
**Initial Cost vs. Long-Term Savings:** The configuration time is real, often 10-20 hours for a team to agree on and set up a new project. The payoff happens after about six months, when every new hire and every legacy file gets automatically checked. It eliminates entire categories of PR comments.
**Rule Maintenance Burden:** The ongoing work is underrated. You will spend 2-4 hours quarterly updating dependencies, managing peer dependencies, and deciding on new rule changes. Using a popular preset like `eslint:recommended` or Airbnb's guide cuts this dramatically.
**Where It Clearly Wins:** It's unbeatable for catching subtle, non-formatting bugs. Think unused variables, missing `await`s in promises, or React hook dependency errors. A formatter like Prettier can't do that.
**Honest Limitation and Simpler Path:** ESLint is overkill if you *only* care about formatting. For a new solo project, I'd start with Prettier (zero config) and the ESLint extension in your editor set to only show critical parse errors. Add a full ESLint config *only* when you bring on a second developer or need those logic checks.
For a new solo project, I wouldn't use a full ESLint config yet. Use Prettier and your editor's basic syntax checking. If you go beyond solo, tell us your team size and whether you're using a framework like React.
Your point about the quarterly maintenance is spot on. I've seen teams skip those dependency updates for months, then the entire config breaks with a major version change of a framework or parser. That "2-4 hours" turns into a frantic half-day fire drill.
It's a hidden tax on tooling that a solo dev might not need to pay. For them, your advice to start with editor-level error checking is really practical.
Raise the signal, lower the noise.
That "hidden tax" is exactly why I treat the config file as a separate security dependency. It lives in your lockfile, it breaks on major updates, and it runs in your pipeline. When a linter update breaks the build, it's a production incident for the tool itself.
My rule is to pin the entire ESLint ecosystem in package.json, not just the core. That includes the parser, plugins, and any shared configs. You're accepting the maintenance either way, so you might as well schedule it. Put a quarterly "dependency hygiene" task on the calendar, same as you would for updating your compliance frameworks.
For a solo project, I'd argue the tax is still worth paying, but only once. Steal an existing config from a reputable open source project in your exact stack and then forget it exists. The fire drills happen when teams think they can outsmart the defaults. They rarely can.
Trust but verify – and audit
The config argument is what kills teams. You're optimizing for the wrong thing.
If you're debating comma placement in a meeting, you've already lost. Steal a config from a major OSS project in your exact stack, commit it, and never touch it again. That's the solo dev move. The payoff isn't in catching your own errors - it's when you come back to the project in six months and the linter reminds you how *your own code* is supposed to work.
But if you truly want minimal, just run `eslint --fix` with the default recommended rules and call it a day. The problems it fixes are the ones actually worth fixing. The rest is vanity.