[Bug]: Unknown rules in configuration are silently ignored instead of throwing configuration errors

[swwind]

Details

When an unknown, misspelled, or unregistered rule (e.g., 'non-existent-rule-name': 'error') is specified in rslint.config.ts, rslint silently ignores the rule. It does not warn the developer or fail the build, which can lead to situations where intended lint checks are never actually executed due to silent typos.

In contrast, ESLint performs strict configuration validation at startup and crashes loudly, preventing developers from continuing with invalid configurations.

---

Detailed Linter Behavior Comparison

rslint Behavior

• Running rslint with an unknown rule succeeds silently.
• The rule is skipped entirely without any logs or diagnostics.
• Example:

  $ npx rslint
  Found 0 errors and 0 warnings (linted 542 files with 9 rules in 2.158s using 8 threads)

ESLint Behavior

ESLint strictly validates rules and plugins at start time and throws errors, unless the rule is set to "off" or 0:

1. Unknown core rule:

   TypeError: Key "rules": Key "non-existent-rule-name": Could not find "non-existent-rule-name" in plugin "@".
   

2. Plugin rule where the plugin is not registered:

   A configuration object specifies rule "some-plugin/non-existent-rule", but could not find plugin "some-plugin".
   

3. Plugin rule where the plugin is registered, but the rule does not exist:

   TypeError: Key "rules": Key "some-plugin/non-existent-rule": Could not find "some-plugin/non-existent-rule" in plugin "some-plugin".
   

Note

If the unknown/unregistered rule is explicitly set to "off" (or 0), ESLint bypasses validation and runs successfully (exit code 0).

---

Steps to Reproduce

1. In rslint.config.ts, add an unknown rule with a non-zero severity (e.g. 'error' or 'warn'):

   export default defineConfig([
     {
       files: ['**/*.ts'],
       rules: {
         'non-existent-rule-name': 'error',
         'import-x/this-rule-does-not-exist': 'error',
       }
     }
   ])

2. Run npx rslint.
3. Observe that the linter completes successfully with exit code 0, completely ignoring the invalid rule keys.

---

Expected Behavior

rslint should perform config validation at startup:

• Match rule names against natively implemented Go rules.
• Match rule names with plugin namespaces against the loaded plugin metadata returned from the worker initialization.
• If a rule name cannot be resolved in either registry, rslint should report a configuration error and fail non-zero (or at least output a warning).
• Parity with ESLint: Validation checks should only run on rules that are enabled (severity is not 'off' or 0), matches ESLint's behavior of silently ignoring unknown rules when disabled.