Flat Config vs. @eslint/eslintrc for Monorepo Plugin Resolution
0 reputation · 29 Aug 2025, 12:53 UTC
Configuration Strategy for Monorepo Plugin Loading
In ESLint v9.0.0+, the transition to Flat Config (eslint.config.js) replaces the legacy hierarchical .eslintrc system. While Flat Config offers explicit control via the files and ignores arrays, monorepos often face challenges when different packages require varying versions of the same plugin.
There is a trade-off between fully adopting the native Flat Config structure, which requires plugins to be imported as JavaScript objects, and using the @eslint/eslintrc compatibility package to maintain legacy extends behavior during a phased migration.
When utilizing Flat Config in a workspace with multiple dependency versions, it is unclear how the resolution mechanism handles plugin collisions or version overrides compared to the legacy directory-based cascading system.
- Does native Flat Config resolution prioritize the nearest
node_modulesfor plugin imports in a monorepo? - How does the
@eslint/eslintrccompatibility layer resolve plugin versions when merging legacy configs into a Flat Config array?
eslint