-
Notifications
You must be signed in to change notification settings - Fork 4.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove including wp-polyfill with default create-block generation #35410
Comments
Removing the polyfills sounds reasonable to me.
Though this option is safer, maybe it's overkill? 🤔 |
That's a good question if we need the polyfill for plugins/blocks. We probably don't need it as it's going to be included anyway when setting any of the existing WordPress scripts handles that Gutenberg sends to the users. @sgomes, what is your take on that? What would be the case when a plugin would need to explicitly ensure that the polyfill is included on the page? |
Thanks for looping me in, @gziolo! This is all a policy and support decision, and I'm not too well-versed on how Core generally tends to approach these, but I'm more than happy to share my 0.02 money units. I believe that giving control over polyfill loading to plugins would provide somewhat of a disincentive for the right course of action, which is to update a given plugin to native, modern JS — assuming the plugin even has a reason to care about polyfills in the first place. The option of not changing anything about the code or build process and forcing WP to maintain legacy behaviour will likely seem appealing to some time-strapped developers. In general, a plugin's goal should be unrelated to anything around polyfills; plugins should be concerned with the WP functionality they provide, and not the browser environment it happens to run in. WP doesn't need these general polyfills and opts not to load them, so if a plugin itself needs or wants them, then I would argue that it's a plugin in need of some work to be compatible with newer versions of WP, or a plugin that's overly concerned with matters beyond its scope. Besides, if a plugin really needs a specific polyfill (say, for something like Intersection Observers) it can always opt to ship it alongside its code. And it could even ship them all, if it's, say, a plugin specifically designed to maintain IE11 support. But giving plugins easy access to large spectrum polyfilling through Core functionality seems like opening the ecosystem up to potential problems in the future. Hope this helps! |
I read your response as - it's time to phase out polyfills from tools that the community uses 😄 The only risk I see is that some plugins might break when they update |
That's a much less roundabout way of expressing my thoughts, yes! 😄
Even if it were to happen a lot in practice, I think that would be fine. Situations like this are generally why projects have major versions, release notes, and, if we want to be really extensive and supportive, migration guides. |
What problem does this address?
The default wp-scripts will include the polyfills dependency due to this line
With the support for IE11 removed, we no longer need the polyfill by default. It adds additional overhead with little gain, see #35038 for more details.
What is your proposed solution?
The easiest to solve would be to just remove the
injectPolyfills: true
from wp-scripts webpack config. I'm not sure if this would cause problems with backward compatibility or not.An alternate would be to setup and environment variable to trigger polyfills, ideally we default it to false and then instruct people who need it to set to true. Suggestion:
WP_WEBPACK_USE_POLYFILLS
We could then change the config line to:
injectPolyfill: process.env.WP_WEBPACK_USE_POLYFILLS
Thoughts? cc: @gziolo @ryanwelcher @aristath
The text was updated successfully, but these errors were encountered: