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
Is your feature request related to a problem? Please describe.
https://github.com./tc39/proposal-regex-escaping/ has been in TC39 purgatory for almost 8 years now and it's still at stage 1, despite what seems to be fairly wide consensus that it's a useful feature that should be standardized. In light of that, it seems like a good candidate for inclusion in a standard library, for later deprecation if and when the proposal ever gets rolled out.
Describe the solution you'd like
A function called something like regexEscape with an API something like this:
Ideally, it'd support contexts both within and outside of character classes, as well as all flavors of regex, including the upcoming v flag. It'd escape the minimal set of characters needed to be agnostic to all those contexts (i.e. no escaping of non-ASCII characters or always-literal characters like _), and for other characters, it would use the most readable escape where possible (e.g. \. for a literal period), falling back to hex escapes where that's impossible (e.g. \x3c for <).
Describe alternatives you've considered
Wait another 8 years I guess? 😅
Alternative APIs would involve versions that take options (e.g. specifying flags or whether the context is within a character class or not) or exporting different versions of the function for these use cases. Both of these options would make the implementation significantly more complex.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
https://github.com./tc39/proposal-regex-escaping/ has been in TC39 purgatory for almost 8 years now and it's still at stage 1, despite what seems to be fairly wide consensus that it's a useful feature that should be standardized. In light of that, it seems like a good candidate for inclusion in a standard library, for later deprecation if and when the proposal ever gets rolled out.
Describe the solution you'd like
A function called something like
regexEscape
with an API something like this:Ideally, it'd support contexts both within and outside of character classes, as well as all flavors of regex, including the upcoming
v
flag. It'd escape the minimal set of characters needed to be agnostic to all those contexts (i.e. no escaping of non-ASCII characters or always-literal characters like_
), and for other characters, it would use the most readable escape where possible (e.g.\.
for a literal period), falling back to hex escapes where that's impossible (e.g.\x3c
for<
).Describe alternatives you've considered
Wait another 8 years I guess? 😅
Alternative APIs would involve versions that take options (e.g. specifying flags or whether the context is within a character class or not) or exporting different versions of the function for these use cases. Both of these options would make the implementation significantly more complex.
The text was updated successfully, but these errors were encountered: