Missing configuration error when ESLint cannot resolve config file in flat‑config mode

Question

Determine whether ESLint can guarantee a safe rollback of configuration changes when switching between flat‑config mode and the legacy .eslintrc format without altering the resolved rule set, ignores, or language options for a given file.
Flat‑config does not cascade like .eslintrc, the discovered config file is used for that run, and file/ignore paths are interpreted relative to the config file location. The active configuration also depends on the current working directory and an explicit --config flag, while rule defaults and parser/plugin versions may differ between ESLint releases. Until the project decides whether legacy .eslintrc remains a temporary escape hatch or is removed entirely, a config rollback is not safely reversible across the two modes.

Should ESLint treat legacy .eslintrc as a first‑class config source that can be safely rolled back to flat‑config without changing behavior?
Is there a versioned compatibility layer that ensures identical resolved configurations when switching between the two modes?
What verification steps are needed to confirm that a config rollback preserves lint results across flat‑config and .eslintrc modes?

Wasi · Answer

Rollback Safety Analysis
ESLint cannot guarantee a safe, behavior-neutral rollback of configuration changes when switching between flat-config mode (eslint.config.js) and the legacy .eslintrc format. Because the two systems utilize fundamentally different resolution engines, reverting from one to the other is likely to alter the resolved rule set, ignore patterns, and language options for your files.

Why Parity Cannot Be Guaranteed
The discrepancy arises from three primary architectural differences:

Cascading vs. Single-File: Legacy config uses a cascading hierarchy, searching parent directories for additional .eslintrc files. Flat config is non-cascading; it uses a single discovery point and does not automatically inherit settings from parent folders.
Ignore Resolution: In legacy mode, ignores are handled via .eslintignore files or ignorePatterns. In flat config, ignores are integrated directly into the configuration array as global or file-specific objects.
Plugin Loading: Legacy config relies on string-based plugin names resolved via node_modules. Flat config uses standard JavaScript imports, changing how plugins are loaded and scoped.

Verification Steps for Configuration Parity
If you must attempt a rollback or migration and need to verify that linting results remain identical, use the following process:

Compare Resolved Configs: Run the print-config command for a specific target file in both modes and diff the resulting JSON output.
# Legacy Mode
eslint --print-config path/to/file.js > legacy-config.json

# Flat Config Mode
ESLINT_USE_FLAT_CONFIG=true eslint --print-config path/to/file.js > flat-config.json

Diff Lint Output: Execute linting on a representative set of files in both modes and compare the logs to identify missing or additional violations.

Audit Ignores: Manually verify that every pattern in .eslintignore has been explicitly mapped to the ignores property in the flat config array.

Compatibility Layers
There is no native, versioned compatibility layer that ensures identical resolved configurations automatically. While utilities like @eslint/eslintrc exist to help migrate legacy configs into the flat format, they do not provide a bidirectional, lossless synchronization that guarantees identical behavior during a rollback.

Diagnostic Detail Required: Are you using a monorepo with nested .eslintrc files? If so, a rollback to legacy mode will restore cascading behavior that flat config cannot replicate without manual duplication of rules across multiple config files.

Missing configuration error when ESLint cannot resolve config file in flat‑config mode

1 answer

Rollback Safety Analysis

Why Parity Cannot Be Guaranteed

Verification Steps for Configuration Parity

Compatibility Layers

Your perspective belongs here.

0 question comments