Closed SCWR closed 2 years ago
slevithan
commented
2 years ago What is the issue you've encountered?
You're making some assumptions about browser support here that do not seem relevant. XRegExp has supported \p{...} for matching Unicode categories, etc. for something like 14 years now (before JS regex syntax supported it natively), going back to at least Firefox 3.
SCWR
commented
2 years ago For my scenario, I need compatibility with Firefox 67
Then I use the xregexp base ability to do forward matching. That's your example https://gist.github.com/slevithan/2387872
This line is executed when using the XRegexp base capability
However, Firefox needs to be upgraded above 78 to support \p{...}
https://caniuse.com/?search=%5Cp
Whether the above functions are required
If not, is it possible to make a plug-in
Base capabilities are one package, others are loaded on demand
By the way, I solved this problem by tweaking compatible versions
slevithan
commented
2 years ago Ah, now I see what you mean. That line you highlighted in xregexp.js gets translated automatically by babel-plugin-transform-xregexp when generating xregexp-all.js. You could modify the build script if you wanted to not include all the plugins while still using Babel to do this transformation. You could also use any XRegExp version prior to v5.0.0 (where this line was added to support an extended set of capture name characters as part of #247) to get around this.
If not, is it possible to make a plug-in
Base capabilities are one package, others are loaded on demand
Yes, I'm open to this and would be happy to see pull requests that show how this might be achieved.
I found itsues and found that
\pintroduced may be because of this #228.\pStart support is 2018 But Firefox is only supported until 78 (2020). What is the way to block the use of\pNeed to be compatible with Firefox 67 in my use scenario.https://github.com/slevithan/xregexp/blob/2dcf16d0aef8b985767886e0d392ce735fd7bff9/src/xregexp.js#L1871