Rename wp-polyfill-ecmascript

[earnjam]

We're continuing to see reports of issues with ModSecurity due to a very common ruleset including a rule that blocks files with ecmascript in the filename. The polyfill file uses the name wp-polyfill-ecmascript.min.js, so it ends up getting blocked by the rule, resulting in the editor breaking completely. See #10075 for more details.

It seems unreasonable to expect all hosts to put an exception rule in ahead of 5.0 to make sure this doesn't happen. Any reason why we can't just rename the file?

I went with wp-babel-polyfill on this PR, but not stuck to that. Just used it because that's where the polyfill originates from.

[youknowriad]

At that point, I'd just drop it and add it as a script file for wp-polyfill. Thoughts @aduth?

[aduth]

At that point, I'd just drop it and add it as a script file for wp-polyfill. Thoughts @aduth?

That's fine with me.

Aside: TIL serious hackers use "ecmascript" in their 'sploits. 🤦‍♂️

[aduth]

An issue with this revised approach is that we're referencing the CDN directly, since we're no longer going through the gutenberg_register_vendor_script function to download a local copy of the file. This won't be acceptable for the plugin distributable or the core merge.

Can we keep the gutenberg_register_vendor_script and just rename it to wp-polyfill? Not sure how well this interoperates with the equivalent 5.0 beta script which we're otherwise using gutenberg_override_script to override.

[earnjam]

🤦‍♂️ of course. Sorry was only half paying attention here. I’ll update the PR in a bit

[earnjam]

So I moved it back to using gutenberg_register_vendor_script(), but you're correct in that this would now load the @babel-polyfill script twice if someone is running latest core beta + latest Gutenberg.

We'll need to update this in core in tools/webpack/packages.js as well.

[youknowriad]

@earnjam A simple fix (which is also necessary to ensure backwards compatibility) is to keep wp-polyfill-ecmascript registered but it's content should be null (like the previous wp-polyfill) and it should have wp-polyfill as a dependency.

[aduth]

Is this something we want to do away with eventually? Should we make that clearer in the comment? How can we plan to follow-up?

[earnjam]

I'm honestly not sure best course of action here. Realistically, what is the likelihood that plugins are counting on this script handle? If we plan to eventually remove it, how long should we wait?

[aduth]

We could follow the standard deprecation workflow:

https://wordpress.org/gutenberg/handbook/reference/deprecated/

We've done similar before for server-side features in either (a) enqueuing an inline script to run wp.deprecated( '...' ) messaging or (b) _doing_it_wrong. The former seems easiest, since the second would be difficult in determining whether there are scripts which define a dependency on the script.

Examples:

• https://github.com/WordPress/gutenberg/pull/10153/files#diff-620130744b6b73b822a3df609671d930L864
• https://github.com/WordPress/gutenberg/pull/8276/files#diff-620130744b6b73b822a3df609671d930L1214

[earnjam]

wp-polyfill-promise looks like a good example of prior art. What version should we set for removal?

[aduth]

Two versions out, 4.5, which may or may not actually happen.

[aduth]

To remedy failing tests, you may need to rebase the branch or merge master to account for #11318.

[aduth]

Added the deprecation warning in 3fc153f

[aduth]

I dunno who one pings these days as a heads-up for scripts in the 5.0 merge; @pento @atimmer maybe? Proposed here is that we'll not need the wp-polyfill-ecmascript for a final 5.0.

[aduth]

This inadvertently broke the plugin packaging script. See: #11696