You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What do you think about adding the regex package to offer extended JS regex syntax (atomic groups, possessive quantifiers, subroutines, etc.)? A couple of options:
Use it by default. This might be a good approach since regex uses a strict superset of JS regex syntax, and all of its extended syntax is an error in native JS regexes.
Potentially add an option to enable free spacing mode (flag x), which is on by default in regex but could be disabled by default in RexReplace to avoid changing existing behavior.
Add an option (or potentially reuse the existing -E/--engine) to switch from native JS syntax to regex.
In this case, presumably you'd leave all of regex's implicit flags enabled.
Note: Since RexReplace would need to call regex with dynamic input rather than using it with backticks as a template tag, that would work like this: regex({raw: [<pattern-string>]}) or regex(…)({raw: [<pattern-string>]}). Something like the following options might work best if regex was used by default:
Edit: If you also wanted to disable flag v's changes to escaping rules within character classes (to avoid breaking changes), you could add the options disable: {v: true} and unicodeSetsPlugin: null. You can see more details about all of regex's options here, but essentially, option disable: {v: true} means to use flag u even in environments that support v natively, and unicodeSetsPlugin: null tells regex not to apply flag v's escaping rules when using flag u. Note that regex always uses flag u or v, so using the library would implicitly set RexReplace's -u/--unicode option. But I think it might be a good breaking change to always implicitly use Unicode-aware mode anyway, since Unicode-unaware mode can silently introduce many Unicode-related bugs, doesn't get the benefit of strict errors for weird legacy syntax, and doesn't support \u{…}, \p{…}, or \P{…}. (Flag u has been supported since ES6/ES2015.)
The text was updated successfully, but these errors were encountered:
Its a great idea. It was actually how I came across your regex lib. I have been considering changing the default flags and got sucked into the world of why regex is like it is. However, it will demand a version bump as things might break. And that is ok.
And thank you so much for providing the current default behaviour also. Ill dive into this during september after my current project.
Love the project! 😊
What do you think about adding the regex package to offer extended JS regex syntax (atomic groups, possessive quantifiers, subroutines, etc.)? A couple of options:
regex
uses a strict superset of JS regex syntax, and all of its extended syntax is an error in native JS regexes.x
), which is on by default inregex
but could be disabled by default in RexReplace to avoid changing existing behavior.-E
/--engine
) to switch from native JS syntax toregex
.regex
's implicit flags enabled.Note: Since RexReplace would need to call
regex
with dynamic input rather than using it with backticks as a template tag, that would work like this:regex({raw: [<pattern-string>]})
orregex(…)({raw: [<pattern-string>]})
. Something like the following options might work best ifregex
was used by default:Edit: If you also wanted to disable flag
v
's changes to escaping rules within character classes (to avoid breaking changes), you could add the optionsdisable: {v: true}
andunicodeSetsPlugin: null
. You can see more details about all ofregex
's options here, but essentially, optiondisable: {v: true}
means to use flagu
even in environments that supportv
natively, andunicodeSetsPlugin: null
tellsregex
not to apply flagv
's escaping rules when using flagu
. Note thatregex
always uses flagu
orv
, so using the library would implicitly set RexReplace's-u
/--unicode
option. But I think it might be a good breaking change to always implicitly use Unicode-aware mode anyway, since Unicode-unaware mode can silently introduce many Unicode-related bugs, doesn't get the benefit of strict errors for weird legacy syntax, and doesn't support\u{…}
,\p{…}
, or\P{…}
. (Flagu
has been supported since ES6/ES2015.)The text was updated successfully, but these errors were encountered: