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 where the callee is a recognized globalRegExpconstructor and the pattern or flags are statically known strings. Spread arguments and unresolved runtime expressions are ignored. - When a regex literal is passed to
RegExp(...)with an unresolved second flags argument, rslint does not report on the literal because the runtime flags may override the literal's own flags. - 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.