Several linter rules compile regexes from user configuration with unwrap / expect, or convert compilation errors into None / fallback behavior. Invalid regex config should not panic during linting, and it should not silently disable or change rule behavior.

This issue tracks the affected sites and should be closed once they either report a configuration error consistently, escape user input before building generated regexes, or have explicitly documented literal-fallback semantics with tests.

Panic sites

• crates/oxc_linter/src/utils/jest.rs:324

  • matches_assert_function_name does Regex::new(pattern).unwrap() on converted assertFunctionNames patterns.
  • Reached by jest/prefer-ending-with-an-expect and shared jest / vitest expect-expect logic.
  • User-provided values flow through convert_pattern; malformed regex metacharacters can become a runtime panic.

• crates/oxc_linter/src/rules/typescript/no_require_imports.rs:126

  • allow patterns are documented as regexes and compiled with Regex::new(pattern).unwrap() during matching.
  • Invalid configured patterns can panic at lint time.

• crates/oxc_linter/src/rules/jsdoc/require_param.rs:185

  • checkTypesPattern is compiled with .expect("config.checkTypesPattern should be a valid regex pattern").
  • Invalid user config can panic instead of returning a config error.

• crates/oxc_linter/src/rules/react/jsx_handler_names.rs:161 and :177 cancelled, see comment

  • Dynamic regexes are built with RegexBuilder::new(...).build().expect(...).
  • Inputs are escaped first, so this is probably lower risk than the config-regex cases, but it is still dynamic regex construction with a panic path and should be reviewed.

Silent invalid-pattern handling

• crates/oxc_linter/src/rules/shared/jest_vitest/valid_title.rs:369, :375, :386, :389

  • compile_matcher_pattern uses Regex::new(...).ok()?.
  • Invalid matcher patterns make the config entry disappear instead of surfacing a configuration error.

• crates/oxc_linter/src/rules/shared/jest_vitest/valid_title.rs:411 fix(linter/valid-title): escape disallowed words regex #23742

  • disallowedWords are interpolated into a generated regex and let Ok(...) = ... else { return; } silently skips the check if compilation fails.
  • The words are only partially escaped (.), so other regex metacharacters can alter or break the generated regex.

• crates/oxc_linter/src/rules/typescript/ban_ts_comment.rs:153

  • Invalid descriptionFormat compiles to None, silently changing DescriptionFormat behavior.

• crates/oxc_linter/src/rules/vitest/consistent_test_filename.rs:115 and :119

  • Invalid allTestPattern / pattern config returns None; callers then fall back to defaults.
  • This can make an invalid configured pattern look like a valid default configuration.

• crates/oxc_linter/src/rules/eslint/capitalized_comments.rs:87 fix(linter): report invalid capitalized-comments ignore patterns #23608

  • Invalid ignorePattern becomes None, so configured comments are no longer ignored without any config error.

• crates/oxc_linter/src/rules/eslint/no_param_reassign.rs:109

  • Invalid entries in ignorePropertyModificationsForRegex are skipped via if let Ok(regex).

• crates/oxc_linter/src/rules/vue/prop_name_casing.rs:244

  • Slash-wrapped ignore patterns are treated as regexes, but invalid regexes simply do not match via is_ok_and.

• crates/oxc_linter/src/rules/node/handle_callback_err.rs:53 fix(refactor/node/handle-callback-err): reject invalid regex config #23740

  • Strings starting with ^ are treated as regexes, but invalid regexes fall back to plain string matching.
  • This may be intentional compatibility behavior, but it should be confirmed and tested/documented.

• crates/oxc_linter/src/rules/shared/jest_vitest/no_large_snapshots.rs:272

  • Invalid configured allowed snapshot patterns fall back to exact string matching.
  • This may be intentional literal fallback behavior, but it should be confirmed and tested/documented.

• crates/oxc_linter/src/rules/eslint/no_warning_comments.rs:231 cancelled, see comment

  • Generated patterns are compiled with .ok() inside filter_map.
  • Inputs appear escaped, so this may be low risk, but the current code would silently drop a term if generated regex compilation ever fails.