Closed pygy closed 4 years ago
Actually, wait... This will cause a Regexpocalypse that will not be easy to fix once this is live (because a codemod would rely on Babel, which would catch the update automatically because the way both Babel and regexpu-core rely on semver).
I don't think that the situation is as tragic as you picture it, for a few reasons:
/u
(hopefully soon, since it's supported by every browser version with > 1.5%
market share), their code will be broken regardless of this PR.Let's roll with it then :-)
Thanks @pygy for providing this!
I agree with the arguments outlined by @nicolo-ribaudo and therefore accepted this PR.
Published new release to npm as v0.6.3 - https://www.npmjs.com/package/regjsparser/v/0.6.3.
Thanks once again @pygy !
Please see issue #101 . This change introduced a bug.
Thanks for reporting this. I most likely have some time over the weekend to look into this.
@nicolo-ribaudo, @pygy, @jens-duttke Do you think it's better in the meantime to make a new release with the change removed for now?
I think that it's ok to wait a few days. If you end up not having time to fix it please ping me!
Digging into this, when reading the JS RegExp gramma, I am not sure why /}/u
is supposed to be rejected. That is, I think this should parse as:
...
Atom
PatternCharacter
SourceCharacter
But SourceCharacter
has no quantification on the unicode u
flag. See the documentation here:
https://www.ecma-international.org/ecma-262/10.0/index.html#prod-PatternCharacter
Can someone give me a pointer what I am missing here?
Once it's clear to me why /}/u
is supposed to be rejected, I hope to be able to fix the regression in #101 .
Hi @jviereck
This fixes https://github.com/mathiasbynens/regexpu-core/issues/36 and thus https://github.com/babel/babel/issues/11138
Edit: force push for code styling reasons.