I have a biased interest as the creator of the new regex library (which is a spiritual successor to the broadly-used XRegExp library which has been around since ES3 days), but still I think it would be significantly beneficial for JavaScript programmers, both people who are already using the regex library and people who would discover there is a better and more readable way to write native JavaScript regexes.
From its readme:
regex creates readable, high performance, native JavaScript regular expressions with advanced features and best practices built-in. It's lightweight (6.5 KB minified and brotlied) and supports all ES2024+ regex functionality.
Highlights include support for free spacing and comments, atomic groups via (?>…) which can help you avoid ReDoS, subroutines via \g<name> which enable powerful composition, and context-aware interpolation of RegExp instances, escaped strings, and partial patterns.
With the regex package, JavaScript steps up as one of the best regex flavors alongside PCRE and Perl, and maybe surpassing C++, Java, .NET, and Python.
Implementation should be straightforward compared to any other new regex flavor because it's a lightweight library that runs on the client, and its features are a strict superset of native JavaScript regexes with flag v enabled. All of its extended features are already available in flavors that regex101 supports.
Following is a complete list of the changes that would be needed to support the JavaScript regex flavor, compared to the existing support for the "ECMAScript (JavaScript)" flavor:
Disable flag u (unicode), since flag v is always enabled.
Flag v (vnicode) is always enabled.
Flag x (extended) is available and always enabled.
Whitespace (specifically space and tab) is also ignored within character classes). This works like PCRE's flag xx (which regex101 doesn't yet list as an option) and Java's x flag (which is supported by regex101, although Java allows any whitespace in character classes with flag x).
Flag n (non-capturing) is available and always enabled.
Works the same as flag n in .NET (which regex101 already supports as an option) and PCRE (where regex101 doesn't yet list it as an option).
Tooltip and explanation for syntax (…) should describe it as a non-capturing group, which is already supported by regex101 for the .NET flavor with flag n enabled.
Highlight all numbered backreferences (\1, etc.) as errors, since numbered backreferences to named groups are disabled by the always-on flag n (different from .NET, but the same as Ruby and C++ with flag n).
Don't show numbered groups in the "Match Information" card; only named groups (due to flag n).
Highlight syntax (?>…) as an atomic group.
Works the same as (?>…) in PCRE, Java, and .NET, where regex101 already supports atomic groups.
Highlight syntax \g<name> as a subroutine.
Works the same as \g<name> in PCRE, where regex101 already supports subroutines.
Change the delimiter options to only include `.
There is detailed documentation for all of these features in the regex package's readme, and of course I would be happy to help however I can.
Flavor Request
I have a biased interest as the creator of the new
regexlibrary (which is a spiritual successor to the broadly-used XRegExp library which has been around since ES3 days), but still I think it would be significantly beneficial for JavaScript programmers, both people who are already using theregexlibrary and people who would discover there is a better and more readable way to write native JavaScript regexes.From its readme:
Implementation should be straightforward compared to any other new regex flavor because it's a lightweight library that runs on the client, and its features are a strict superset of native JavaScript regexes with flag
venabled. All of its extended features are already available in flavors that regex101 supports.Following is a complete list of the changes that would be needed to support the JavaScript
regexflavor, compared to the existing support for the "ECMAScript (JavaScript)" flavor:u(unicode), since flagvis always enabled.v(vnicode) is always enabled.x(extended) is available and always enabled.xx(which regex101 doesn't yet list as an option) and Java'sxflag (which is supported by regex101, although Java allows any whitespace in character classes with flagx).n(non-capturing) is available and always enabled.nin .NET (which regex101 already supports as an option) and PCRE (where regex101 doesn't yet list it as an option).(…)should describe it as a non-capturing group, which is already supported by regex101 for the .NET flavor with flagnenabled.\1, etc.) as errors, since numbered backreferences to named groups are disabled by the always-on flagn(different from .NET, but the same as Ruby and C++ with flagn).n).(?>…)as an atomic group.(?>…)in PCRE, Java, and .NET, where regex101 already supports atomic groups.\g<name>as a subroutine.\g<name>in PCRE, where regex101 already supports subroutines.`.There is detailed documentation for all of these features in the
regexpackage's readme, and of course I would be happy to help however I can.