IE11 + core-js@3.6.4 String.prototype.split doesn't work with regexp

[kmsheng]

repo to reproduce
https://github.com/kmsheng/core-js-bug

Note that core-js was imported twice,
one in src/js/index.js and the other one in assets/js/default.js

simlar issue
#741

[jaynetics]

i encountered the same bug, and can confirm that importing core-js into two js files is the root cause. importing it in only one file fixes the problem.

[11101101]

I'm also running into the same issue. My code path results in a second import which causes the bug to manifest.

[pierremanceaux]

In case this helps someone: JakeChampion/fetch#748
It would be great to identify which version of IE11 is/are affected, but it seems pretty recent to me, probably the last build.

[aliaksandr-yermalayeu]

Hi everyone. I am facing the same issue. It is still reproduced in IE11 with the latest version of core-js. However the scenario is pretty tricky to reproduce. So I created a minimal repo with needed steps. Hope it helps.

[sargismarkosyan]

Hi, the issue is reproducible with other regexp too for example '/test/'.split(/\W/) is returning ["/", "t", "e", "s", "t", "/"] but should return ["", "test", ""].

[slowcheetah]

Please show your npm list | grep core-js

[aliaksandr-yermalayeu]

@slowcheetah, will result of yarn list --pattern core-js work for you?

├─ core-js-compat@3.6.4
└─ core-js@3.6.4

[aliaksandr-yermalayeu]

I took a deeper dive into this issue. The problem is caused by this line. It turns out regexp.exec and regexpExec are different references when polyfill is loaded twice.

[steveworkman]

Is there an older version of core-js that does not show this issue? It looks like there were changes related to adding more regexp.exec requires in 3.6.2
Would a downgrade to 3.6.1 work?

[jdreesen]

I downgraded to 3.5.0 yesterday and it works for me.

[aliaksandr-yermalayeu]

The bug was introduced by version 3.6.0 due to support of y flag. In version 3.5.0 exec was never patched in IE.

[toxik]

is reverting the sticky flag support considered?

[slowcheetah]

@toxik Not yet. But I think about it, because I can’t make it work correctly and break nothing

[toxik]

@slowcheetah have you got any news regarding a revert/fix ? thanks

[toxik]

you can upgrade XRegExp to v4.4.0 instead – slevithan/xregexp#300

[scrollbar-ww]

same problem with 3.8.0.
I put a .replace() before call String.split() as a short term fix :
str.replace(someRegexp/g, ' \n').split('\n')

[Jokero]

@zloirock @slowcheetah Are there any plans to revert sticky flag?

[zloirock]

@Jokero sticky flag will not be reverted. Feel free to work on exploring and fixing this issue without it.

[Khartir]

I looked into this a bit. As far as I can tell the issue lies in the way regexp-exec (which is required by string.split) provides the patched exec-function. It creates a new patched function, if regexp-sticky-helpers.UNSUPPORTED_Y is true.

In order for UNSUPPORTED_Y not to be true the regexp.constructor and regexp.sticky polyfills are required.

However, these are not included with regexp-exec, so unless they are explicitly included regexp-exec provides a new patch-function if called in separate files.

So I think the solution would be for regexp-exec not to use UNSUPPORTED_Y to check for support but instead to ensure sticky-support exists requiring regexp.constructor and regexp.sticky.

@zloirock Do you agree? I can try to provide a PR for this, but I am unsure how to do this correctly. Should I use a simple require or is there another way for one polyfill to ensure the presence of another polyfill?

I assume a similar issue could exist with regexp.flags but I have not tested this.

[zloirock]

@Khartir sounds reasonable, you could try to add a PR. I don't think that it could affect .flags - it's an unrelated case.

[marcospont]

My team just experienced this issue because we were running core-js 3.9.1 in our code.
Because of the above mentioned issue, one other library we are using to polyfill CSS variables (css-vars-ponyfill) was producing severe performance issues. The execution time of variables polyfilling was more than 200 seconds when it should be around 5. :)