Why I Use a Shared ESLint Config Across Every Project

The moment I knew I needed a shared config came during a routine code review. I'd flagged a linting issue on a PR for one NHCarrigan project, and the contributor pointed out, very politely, that the exact same pattern existed in another NHCarrigan project I'd merged a week earlier. They were right. The rule existed in one repo, not the other. Both repos had been initialised from the same template, but they'd drifted quietly, independently, in different directions.

That's the real problem with per-project ESLint configuration. Each project diverges over time. A rule gets added in one place when a bug surfaces, and never propagates. A new contributor brings their preferred override into one repo and not the others. What starts as five identical configs becomes five different ones, and nobody can quite remember why.

The fix was a shared package: @nhcarrigan/eslint-config. Every NHCarrigan project consumes the same config from npm. When the config changes, every project picks it up on the next update. There's one source of truth, and the cost of keeping it consistent drops to almost nothing.

I built it on ESLint 9's flat config, which I'd argue is worth the migration even if you don't go the shared-package route. The flat format is genuinely easier to reason about, easier to compose, and gives you a clean place to express overrides without the legacy of cascading config files. I also default to --max-warnings 0 in every project. If a rule is worth having, a warning shouldn't be allowed to sit in the codebase indefinitely. Either fix it, or disable the rule with a comment that explains why.

The broader principle is one I keep coming back to: any standard you want to maintain consistently across multiple projects belongs in a shared package, not in a template. Templates drift. Packages don't. The same approach works for TypeScript config, for vitest config, for any cross-cutting tooling decision. The afternoon I spent setting this up has paid for itself many times over, and every time I start a new project and don't have to think about linting, I'm grateful past-me did the work.

How do you manage tooling consistency across multiple projects? I'd be curious whether others have landed on shared packages, monorepos, or something else entirely.

#ESLint #TypeScript #DevTooling #JavaScript