Flat Config vs. @eslint/eslintrc for Monorepo Plugin Resolution

Resolution Behavior in Monorepos

In ESLint v9.0.0+, plugin resolution depends on whether you use native Flat Config imports or the @eslint/eslintrc compatibility layer. Because Flat Config treats plugins as JavaScript objects rather than string identifiers, resolution shifts from ESLint's internal logic to Node.js's standard module resolution.

Native Flat Config Resolution

Native Flat Configs (eslint.config.js) resolve plugins based on the location of the configuration file. When you import or require a plugin, Node.js looks for the nearest node_modules folder relative to that specific config file.

• Priority: It prioritizes the nearest node_modules. In a monorepo, if packages/pkg-a/eslint.config.js imports a plugin, it will resolve the version installed in packages/pkg-a/node_modules before looking at the workspace root.
• Isolation: This allows different packages in a monorepo to use different versions of the same plugin simultaneously, provided they are not hoisted to a common root by the package manager.

@eslint/eslintrc Compatibility Resolution

The @eslint/eslintrc package acts as a bridge. It uses the legacy resolver to load .eslintrc files and then converts those results into a Flat Config-compatible object.

• Mechanism: It delegates resolution to the legacy system, which searches for plugins using the old string-based lookup.
• Version Selection: Resolution follows the legacy directory-based cascading rules. However, because it relies on the legacy resolver, it is more susceptible to package manager hoisting (e.g., npm or Yarn hoisting a single version to the root), which may override a local package version.

Practical Comparison

Feature	Native Flat Config	@eslint/eslintrc Layer
Resolution Method	Node.js import/require	Legacy String-based Resolver
Scope	Relative to config file path	Cascading directory search
Version Control	Explicit via JS imports	Implicit via extends/plugins

Verification Steps

To verify which version is being loaded in your specific monorepo environment, use the following scoped approach:

1. Install two different versions of a plugin in two separate packages (e.g., pkg-a and pkg-b).
2. In each package's config, add a temporary console.log or a rule that outputs the plugin version.
3. Run ESLint from the workspace root: npx eslint .
4. Compare the output to see if pkg-a and pkg-b are using their local versions or a hoisted root version.

Missing Diagnostic: Which package manager are you using (npm, Yarn, or pnpm)? This significantly changes whether hoisting masks the resolution differences between these two methods.