Hangs when loading module in IE11 - with core-js 3.6.0 or newer, with and without babel sticky-regex polyfill

[perbergland]

v 4.3.0

With core-js 3.6.0 (and newer up to 3.6.5), when loading the module, the call to const parts = XRegExp.union hangs and never returns. core-js 3.6.0 introduced new compatibility stuff for sticky so maybe that’s the core problem?

xregexp/src/addons/build.js

Line 10 in 95eeebe

const parts = XRegExp.union([/\({{([\w$]+)}}\)|{{([\w$]+)}}/, subParts], 'g', {

[perbergland]

I reproduced the error in IE11 also with an empty next.js project with and without regex sticky polyfills by just adding import xregexp from "xregexp" to index.js.

To disable the default polyfill, I used this .babelrc

{
  "presets": [
    [
      "next/babel",
      {
        "preset-env": {
          "exclude": ["@babel/plugin-transform-sticky-regex"]
        }
      }
    ]
  ]
}

This is the loop that never exits because token is an empty string:

[perbergland]

repro repo

https://github.com/perbergland/xregexp-repro-issue-300

[perbergland]

@slevithan is this something you could take a look at? I don’t quite grasp the purpose of the code that hangs

[perbergland]

@josephfrazier any chance you could take a peek?

[slevithan]

@perbergland The line of code you highlighted is just concatenating two different regexes together, and separating them with an “or” (|) operator. The resulting regex is assigned the name parts. The concatenation, in this case, is merely done so that the subParts half of the regex can be reused independently elsewhere in the XRegExp.build file/addon.

Some potential fixes and workarounds:

• If you're up for it: Identify and fix/address the issue within XRegExp.union, starting by finding a reduced error case. The regexes fed to union in the line you’ve pointed out are probably needlessly complex for triggering whatever the issue is in IE 11 with core-js 3.6.0+.
• Use XRegExp without the XRegExp.build addon.
• Update the XRegExp.build addon to not use XRegExp.union there:

const subParts = /(\()(?!\?)|\\([1-9]\d*)|\\[\s\S]|\[(?:[^\\\]]|\\[\s\S])*\]/g;
const parts = /\({{([\w$]+)}}\)|{{([\w$]+)}}|(\()(?!\?)|\\([1-9]\d*)|\\[\s\S]|\[(?:[^\\\]]|\\[\s\S])*\]/g;

[perbergland]

Not sure I understand what you mean, but I ended up removing the dependency on xregexp from my app to fix the IE incompatibility. Feel free to close the issue, I don't care anymore.

[NathanAB]

@perbergland just wanna let you know this issue is totally ruining my day right now. You're not alone 😅

IE11 hangs and is completely broken just by including this library as stated.

[slevithan]

I've starting looking into this. Thanks for the repro repo @perbergland. So far I've learned the issue in IE11 is not being triggered by the identified line per se. It is any invocation of the XRegExp constructor with core-js 3.6.0+. E.g. XRegExp('testregex') will trigger the same infinite loop.

[slevithan]

I've added a fix for this in bece2eb

core-js 3.6.0 introduced new compatibility stuff for sticky so maybe that’s the core problem?

That was indeed the problem. The core-js 3.6.0 sticky polyfill appears to be partially broken or incomplete. I've added a check for incorrect handling of sticky, and made XRegExp treat the y (sticky) flag as unsupported in that case.

[slevithan]

Fix published in v4.4.0.