Having spent the last two weeks migrating several of our cloud billing service repositories to ESLint's flat config (`eslint.config.js`), I've encountered persistent, non-trivial issues within our monorepo structure. The documented examples seem to assume a single-package context, which breaks down when dealing with nested packages, shared configurations, and tooling that relies on the now-deprecated legacy format.
The primary friction points I've identified are:
* **Configuration Inheritance & Overrides:** In a legacy setup, we used `extends` in sub-package `.eslintrc.js` files to pull from a root configuration. The flat config's `extends` is an array of config objects, not sharable config names, making it cumbersome to reuse and override rules for specific sub-packages (e.g., frontend vs. backend services).
* **Plugin Resolution:** Several of our shared configs rely on third-party plugins (like `@typescript-eslint`). In the flat config, plugins seem to be resolved relative to the config file location, not the project being linted. This causes "plugin not found" errors when running ESLint from a sub-package directory if the plugin isn't installed there.
* **Tooling Integration:** Our CI/CD pipeline and IDE integrations (VSCode ESLint extension) are struggling with the new config format, often defaulting to no linting until explicit settings are configured per-workspace.
I'm currently evaluating if we need to:
1. Adopt a single, monolithic `eslint.config.js` at the repo root with complex glob patterns for each sub-package.
2. Maintain separate configs in each package, but duplicate the plugin and parser boilerplate.
3. Revert to the legacy configuration for the monorepo until the ecosystem tooling matures.
Has anyone else in the community undertaken a similar migration for a monorepo? I'm particularly interested in concrete strategies for sharing and overriding plugin configurations across packages without sacrificing maintainability or causing resolver errors.
—EK
Your bill is too high.
Oh yeah, plugin resolution has been a major headache for us too. We got bit by that exact same "plugin not found" error when trying to run linting from a CI script that cd'd into a sub-package.
Our janky workaround was to add the plugins as dev dependencies to the root `package.json`, even though they're only used by specific child packages. It feels wrong, but it kept things moving.
Have you found a cleaner solution for this, or are we all just waiting for better tooling support? It really feels like the flat config system wasn't fully road-tested on complex monorepos.