no-misleading-character-class
Configuration
rslint.config.ts
Rule Details
Disallow characters whose visual rendering is made from multiple code points
(combining marks, surrogate pairs, regional indicators, emoji-modifier
sequences, joined ZWJ sequences) from appearing inside a regex character class
[...]. Such sequences cannot be matched as a single unit by the regex engine
and therefore produce surprising matches.
Examples of incorrect code for this rule:
Examples of correct code for this rule:
Options
This rule accepts an options object:
allowEscape(boolean, defaultfalse) β when enabled, allows combining the troublesome characters inside a character class as long as the combining portion is written using a backslash escape sequence. This applies to regex literals and toRegExp(...)calls whose first argument is a string or no-substitution template literal.
Examples of correct code with { "allowEscape": true }:
Differences from ESLint
- The scope of recognition for the
RegExp(...)constructor is limited to calls whose first argument is directly a string literal, template literal (no-substitution) or regex literal, or where the callee isRegExp/globalThis.RegExp/window.RegExp/self.RegExp/global.RegExp. Patterns constructed through variables, spread arguments, or dynamic expressions are not evaluated. - Suggestions to add the
uflag use a simplified heuristic to decide whether the pattern remains valid under the flag. Patterns with identity escapes on letters (e.g./[π]\a/) are correctly detected as unfixable; more exotic cases may rarely produce a suggestion that ESLint would suppress. - In rare edge cases where a character written as
\q{...}or\p{...}escape appears outside its valid flag context (e.g. without the v flag), the scanner may still treat it as a breaker rather than a plain character.