-
-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disallow use of the RegExp
constructor in favor of regular expression literals (prefer-regex-literals)
#1413
Comments
Rule description makes sense. I have very small experience with regular expressions, though. Can we confirm that we have at least 20 regular expressions in our sample user repositories collection? |
1% ecosystem impact. This will ship in standard 16. All legit cases, IMO. |
"The rule does not disallow all use of the RegExp constructor. It should be still used for 1% ecosystem impact - that's a main criteria for adding new "rule" ? |
The RegExp constructor is still allowed for dynamic regexes. But if there's nothing dynamic in your regex, then you should use the regex literal syntax, e.g. @dmitryverkhovtsev What code were you trying to write that failed with this rule? |
@feross
|
@dmitryverkhovtsev this rule is not supposed to error for that. See the examples here: https://eslint.org/docs/rules/prefer-regex-literals |
side note: be careful that |
Indeed, the example you pasted is not considered an error by this rule. |
https://eslint.org/docs/rules/prefer-regex-literals
Desired config:
There are two ways to create a regular expression:
/abc/u
.RegExp
constructor function, e.g.,new RegExp("abc", "u")
orRegExp("abc", "u")
.The constructor function is particularly useful when you want to dynamically generate the pattern,
because it takes string arguments.
When using the constructor function with string literals, don't forget that the string escaping rules still apply.
If you want to put a backslash in the pattern, you need to escape it in the string literal.
Thus, the following are equivalent:
In the above example, the regular expression literal is easier to read and reason about.
Also, it's a common mistake to omit the extra
\
in the string literal, which would produce a completely different regular expression:When a regular expression is known in advance, it is considered a best practice to avoid the string literal notation on top
of the regular expression notation, and use regular expression literals instead of the constructor function.
Rule Details
This rule disallows the use of the
RegExp
constructor function with string literals as its arguments.This rule also disallows the use of the
RegExp
constructor function with template literals without expressionsand
String.raw
tagged template literals without expressions.The rule does not disallow all use of the
RegExp
constructor. It should be still used fordynamically generated regular expressions.
Examples of incorrect code for this rule:
Examples of correct code for this rule:
Options
This rule has an object option:
disallowRedundantWrapping
set totrue
additionally checks for unnecessarily wrapped regex literals (Defaultfalse
).disallowRedundantWrapping
By default, this rule doesn’t check when a regex literal is unnecessarily wrapped in a
RegExp
constructor call. When the optiondisallowRedundantWrapping
is set totrue
, the rule will also disallow such unnecessary patterns.Examples of
incorrect
code for{ "disallowRedundantWrapping": true }
Examples of
correct
code for{ "disallowRedundantWrapping": true }
The text was updated successfully, but these errors were encountered: