如何调试ESLint的配置合并过程？

Great question—ESLint's config merging logic can feel frustratingly opaque at times, especially when rules stop working for no obvious reason. Let’s break this down with clear details and tools to demystify the process.

Detailed Breakdown of Config Merging Logic #

ESLint’s merging follows a specific priority hierarchy, and different config sections are handled differently:

Priority Order #

1. Local config file (your project’s .eslintrc.* or eslintConfig in package.json) overrides all extended configs.
2. Extended configs are applied from left to right in the extends array—later entries override earlier ones. For example, extends: ['eslint:recommended', 'plugin:react/recommended'] means React’s config rules will take precedence over ESLint’s recommended rules if there’s a conflict.

How Specific Sections Are Merged #

• rules: This is a key-value map where later entries (local config or later extended configs) completely replace earlier ones. If a rule uses an array configuration (like ['error', { allowEmptyCatch: true }]), the entire array is replaced—not just merged with existing options.
  Example:

  // Extended config has:
  rules: { 'no-unused-vars': ['error', { argsIgnorePattern: '^_' }] }
  
  // Your local config replaces it entirely:
  rules: { 'no-unused-vars': 'warn' }
  

• env, parserOptions, globals: These are merged as objects. Local config properties override extended ones, but non-conflicting properties are preserved. For example, if an extended config enables node: true and your local config sets browser: true, both node and browser will be enabled.
• plugins: Arrays are merged and deduplicated. Extended plugins come first, followed by local plugins—order can matter for plugin-specific rule resolution, but rule names are prefixed with the plugin name (e.g., react/prop-types) to avoid conflicts.
• settings: Objects are merged deeply. Local config properties override nested properties in extended configs, but non-conflicting nested properties are kept.

While the official docs touch on this, the details are scattered in the Configuring ESLint section—digging into the "Extending Configuration Files" subheading and related pages will reveal more nuance. For the truly curious, ESLint’s source code (specifically the mergeConfig function in lib/config/config-array.js) shows the exact merging logic.

Tools to View the Final Merged Config #

The easiest way to see exactly what ESLint is using after merging all configs is with a built-in command:

• eslint --print-config <file-path>: Run this in your project root, pointing to any file ESLint would lint (e.g., eslint --print-config src/index.js). It outputs the full, merged config as JSON, including every rule, environment, parser setting, and plugin. This is invaluable for debugging why a rule isn’t behaving as expected—you can check if it’s being overridden or not included at all.

Other useful options:

• VS Code ESLint Plugin: Open the "ESLint" output channel (via View > Output > Select ESLint) to see logs about config loading and rule application. While not as comprehensive as --print-config, it can help spot issues like missing plugins or invalid configs.
• Third-party tools: Tools like eslint-config-inspector provide a UI to explore merged configs, but the built-in --print-config command is usually sufficient for most debugging needs.

Common Pitfalls to Watch For #

• Accidentally overriding rule options: If you set a rule to just 'error' or 'warn' in your local config, you’ll replace any extended rule options entirely.
• Misordering extended configs: If you place a more specific config (like a framework-specific one) before a general one, the general config will override it. Always put more specific configs later in the extends array.
• Hidden overrides in shared configs: Some shared configs explicitly disable rules from eslint:recommended, so check their documentation if rules seem to be missing.

内容的提问来源于stack exchange，提问作者Fabis