Debuggex and regexper are powerful,I agree,that I also hesitate whether there's any reason to publish it.
But I'd like to point out some merits of regulex:
- Regulex is dedicated to ECMAScript RegExp syntax(So I didn't plan to add PCRE support now)
- regexper.com can not point out the syntax error index precisely.(Much JS interpreter can not do that)
- regexper and debuggex both tolerate OctalEscape.
- Regulex can detect invalid backref,which is treated as OctalEscape in Debuggex and regexper.
- Because of OctalEscape's complexity, Debuggex did not parse `(\1)\1\2` correctly ( https://www.debuggex.com/r/_U1r_NxTvLan7h9R ),also regexper.And /^\1(a)$/ will match "a",not "aa".So I treat it as an error.
Specifically, a \n in your regex where group n doesn't exist is actually interpreted as the octal \00n.
If I recall correctly, \1(a) should match just "a" because all groups start out as being empty.
Parsing regular expressions is indeed complex, and we've got a massive suite of tests to make sure our engine works correctly (with respect to the chrome implementation, since that's what most people are using js regexes for).
My little tool didn't intend to act like a extreme powerful and multifunctional tool which debuggex is. I know debuggex need to conform existing regex engines,so it will be more useful and can be widely applied. But what my tool intended is another side,trying to point out errors strictly.Such as /\1(a)/ or /(\1)/ doesn't make sense, so I think the ability to report errors like this will be useful.Although js interpreter's regex engine still supports octal today,but I remove it radically(see the project README).Maybe this little feature is useful for someone. ;)