Description

Thanks for your great work on this plugin!

I was using eslint-plugin-regexp for a while, and now I stumbled upon eslint-plugin-clean-regex. I can see that many rules are very similar in these two plugins.

@RunDevelopment and @ota-meshi, how do you feel about joining forces with each other by merging eslint-plugin-regexp and eslint-plugin-clean-regex into a single project?

Top-level alternations like int|integer are problematic because the word integer integer will never be matched.

In general: Let A and B be a pair of distinct alternatives of the same alternation where A comes before B.
If there ex. a word w in L(A) and x in L(B) \ L(A) such that w is prefix of x, then x can never be matched by B.
In other words: Report if   [ L(B) \ L(A) ] ∩ L(/A[\s\S]*/) != ∅.

Examples:

/a|b/ //ok
/a|aa/ // report that `aa` cannot be matched
/a\b|aa/ // ok
/a|[ab]a/ // report that `aa` cannot be matched
/(?:a|[ab]a)\b/ // ok
/a(a|aa)a/  // report that `aaaa` cannot be matched

Right now, the rule only reports lazy constant quantifiers but it can do a lot more:

If the next character of the lazy quantifier is not a prefix of the lazily quantified element, the lazy modifier can be removed.

Example:

/ab+?c/

This project currently uses ESLint 3 which isn't the latest major version of ESLint. Looking at the releases, it's probably the best move to wait until v6.0 is released.

When I first started this project, it was just a collection of simple rules I came up with to make reviewing regexes easier. But as the project grew and rules became more numerous, my focus started to shift. While the vague promise of "writing better regular expressions" may have been a good umbrella for what I've been doing until now, it doesn't describe the function and goals of the project at all.

Task:

• Describe in a few sentences in plain English what the purpose of this plugin is and how it tries to achieve its goals.
• List non-goals and make it clear that this plugin is opinionated.
• Be brief!

The section will be placed directly below the slogan, so people don't have to search for this information.

Description

I just learned that capturing groups inside negated lookarounds behave interestingly. The captured text of a capturing group is reset after leaving a negated lookaround.

This means that the \1 in /(?!(a))\w\1/ is useless. However, the \1 in /(?!(?!(a)))\w\1/ (double negation) is useless too.

This means that (?!(?!R) for some regex R is equivalent to (?=R) if and only if R does not contain capturing groups.

The no-trivially-nested-lookaround does not account for this right now.

Almost nobody uses empty alternatives and it's easy to forget to delete a | when rewriting regular expressions.

If the only thing preventing two one-character alternatives from being merged is an alternative that cannot start with either characters (from the one-character alternatives), then it's safe to reorder the alternatives and merge the one-character alternatives.

Example:
(?:a|foo|b) == (?:a|b|foo) == (?:[ab]|foo)

I already added a util method that can detect the first character of an alternative, so this should be easy to implement.

/[0-9]/ // replace with \d
/[a-zA-Z_\d]/ // replace with \w
/[a-zA-Z_\d-]/ // replace with [\w-]
/[a-z_\d]/i // replace with \w

This rule should only affect \d\D\w\W.

Some assertions are plain unnecessary, either because they are always true or always false.
Examples:

/a\ba/ // always false
/a\Ba/ // always true
/foo^/ // note that there is no m flags
/$bar/
/foo(?!x)\s+bar/

Unused nested capturing groups are likely meant to be non-capturing groups:

Examples:

/(foo(bar))/
/(foo(\s+|\s*,\s*)?bar)/

Examples:

/(\b)+/
/(?:(?!a))/

Some seemly innocent patterns can have a run time of O(n^2). This can be a vulnerability as pointed out here and further explained here.

"Even extremely simple regexes like /a+b/ show this O(n^2) behavior for inputs like 'a'*n." ('a'*n means n-many a characters.)

The purpose of this rule is to detect these patterns.

From what I've seen, the general rule seems to be: If there exists some set of paths AB*C in the regex R such that x = (L(A) ∩ L(B*)) \ ({ε} ∪ L(C)) is not the empty set, then R will take Ω(n^2) many steps to reject a word w ∈ x^n \ L(R).

Please note the Omega in the time complexity bound. This is not a typo. The backtracking algorithm might actually take more than O(n) steps to reject a suffix of the input string.

There are multiple ways to express a character class which accepts all characters but you should choose one and stick with it to make your regexes easier to understand.

Examples:

/[\s\S]/, /[\d\D]/, /[\w\W]/, /[^]/

Notes:
If present, we could even take advantage of the s flag.

This should also detect alternations which are equal to the set of all characters. Examples:

/(?:\s|\S)/, /\s|\S/, /(?:.|\s)/, /.|\D/

To prevent exponential backtracking, the alternatives of a quantified group have to be disjoint (aside from the empty string and assertions).

For a RE /(A1|A2|...|An)*/, its alternatives have to disjoint such that:
∀ Aj: ( L(/(A1|...|Aj-1|Aj+1|An)*/) ∩ L(/Aj*/) ) \ {ε} = ∅ where L is a function which returns the language of the given RE and ε is the empty string.

This will be difficult to implement because we need to be able to construct an NFA from the RE and assertions don't make this any easier.

Example:

/(?:a|b|c)/ => /[abc]/
/(?:\w|-|\+|\*|\/)+/ => /[\w+*/-]+/
/(a|b|c)/ => /([abc])/
/(?:[ab]|c)/ => /[abc]/
/(?:a|b)/ // stay like this

Note:
This rules should only affect groups with a) >= 3 alternatives or b) at least one character class.

If a pattern can be simplified by adding the i flag, it might be a good idea to suggest that to the user.

The conditions for this rule to add the i flag (and subsequently simplify the pattern) are:

1. The i flag isn't present.
2. All characters, character classes, and character sets match the same character(s) regardless of the i flag (aka. the flag doesn't change the meaning of the pattern.)
3. There is at least one character class that can be simplified because of the added i flag. E.g. a character range can be removed, or a character class can be replaced by a character or character set, or similar.

Adding flags willy-nilly might cause some problems, so I don't know whether it should be auto-fixable. Does ESLint have a suggestion mode (aka "you might want to do this but I (ESLint) won't auto-fix it for you")?

Standard assertions \b, \B, ^, and $ are efficiently implemented and easy to understand. That's why they should be preferred over lookaround assertions which do the same.

Examples:

/foo(?!\w)/ => /foo\b/,
/foo(?!.)/ => /foo$/m

Stuff like this:

/;+.*/ == /;.*/
/\d+\w+/ == /\d\w+/
/\w+\d+/ == /\w+\d/
/\w+\d*/ == /\w+/

More general: Let A be a subset of B.

/A{n,m}B{o,}/ == /A{n}B{o,}/
/B{n,}A{o,p}/ == /B{n,}A{o}/

The new rule should detect concatenation like this and report them. In trivial cases, it might even provide a fixer.

A migration tool and a guide are needed. This can only be done once eslint-plugin-regexp has progressed far enough.

The function the rule relies upon assumes that expressions will always be matched left-to-right which isn't the case for lookbehinds.

Example:
The pattern \w+(?<=a\1a(b)) matches abab but not aab.