Alright team, we've been running this setup for a year now with a big, messy monorepo and a huge dev team. The key for us was finding an ESLint config that works out-of-the-box, stays out of our way, and keeps PR reviews focused on logic, not style debates.
We landed on `eslint-config-airbnb` with a few tweaks. It's opinionated, which is exactly what you need with 20+ devs. No bikeshedding. The React rules are fantastic. The only additions we made were extending `prettier` (to avoid formatting clashes) and adding the `eslint-plugin-react-hooks` plugin for the Rules of Hooks.
Our `.eslintrc.js` is basically:
```
module.exports = {
extends: ['airbnb', 'airbnb/hooks', 'prettier'],
plugins: ['react-hooks'],
rules: {
'react/react-in-jsx-scope': 'off', // for Next.js
},
};
```
The onboarding win? New devs can clone, install, and have linting working instantly. The config handles JSX, hooks, imports, and even accessibility via `jsx-a11y`. It's a solid foundation you can then lightly customize. What's everyone else using for large teams?
I'm a sales ops lead at a mid-sized SaaS company with around 15 engineers. We run a React/TypeScript frontend, and I helped our tech lead evaluate these configs because I handle onboarding and workflow standardization.
Core comparison for our team:
**Team friction and onboarding time**: Airbnb is a known standard. New hires from most bootcamps or other companies have seen it. That cut our initial "how do I format this" questions by about 80% immediately. The specificity means less debate.
**Configuration and maintenance overhead**: The plain `eslint-config-airbnb` bundle is near-zero config, but adding Prettier was mandatory for us to stop line-length debates. Without it, we had constant clashes between ESLint's stylistic rules and our IDE formatters.
**Ruleset rigidity vs. flexibility**: It's extremely opinionated. We had to turn off `react/react-in-jsx-scope` for Next.js and changed the `function` declaration rule. For anything else, the team vote was to keep the Airbnb rule unless it blocked a feature. This rigidity is the main benefit for a large team.
**Performance impact in our monorepo**: We didn't measure exact seconds, but on our older laptops, the full lint run as a pre-commit hook felt sluggish. We had to add `--max-warnings 0` and eventually move linting to CI only for full runs, which added about 3 minutes to our pipeline.
My pick is also Airbnb's config, specifically for teams over 10 where consistency trumps individual preference. If your team is already deeply bought into another style guide or uses a framework like Next.js heavily, I'd need to know how much you're willing to override defaults and if you use TypeScript.
Your breakdown of the onboarding and maintenance aspects aligns perfectly with my experience on larger projects. The point about Airbnb being a known standard is critical for reducing cognitive load during integration.
However, I'd offer a counterpoint on **Configuration and maintenance overhead**. While it's near-zero initially, the bundle's dependency chain becomes a maintenance liability over multi-year projects. We've experienced breaking changes in transitive dependencies (like `eslint-plugin-react`) that required manual pinning or intervention, moving it from "zero config" to "periodic dependency management." This isn't unique to Airbnb, but its monolithic nature amplifies the risk.
For the performance impact you mentioned, consider integrating linting with your CI pipeline in a staged manner - only run heavyweight rules like `import/no-cycle` on PRs, not on every save. This mitigates the older laptop issue without sacrificing code quality.
—KM
"Works out of-the-box" and "stays out of our way" until you need to update a major React version and the monolithic Airbnb config lags behind for six months. Been there, got the frustrating PRs where the linter rejects perfectly valid new syntax.
That "solid foundation" is also a philosophy lock-in. You're buying their entire opinion on everything from array-callback-return to preferring dot notation. For a team of 20+, maybe that's fine, but it also means any future, more sensible rule from the core ESLint team gets ignored if Airbnb hasn't adopted it yet.
Ever look at the sheer dependency tree it pulls in? It's a small wonder it *does* work instantly.
FOSS advocate