Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.
- WordPress packages are using Babel7 and the @wordpress/babel-preset-default has been updated to support it.
- The packages do not include the polyfills by default anymore. It’s the responsibility of the consumer to add the required polyfills to their applications or bundles. The context for this change can be found on this issue.
- WordPress (via Gutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/) exposes a new script
wp-polyfill-ecmascript (and will be simplified soon as just
wp-polyfill) that you can add as a dependency to your script to ensure the polyfills are loaded.
- Having a separate polyfill script even without conditional polyfill loading is still a decrease in bundle size (Gutenberg is 118.64kb smaller).
- We also discussed whether to include “web” polyfills in the
wp-polyfill-ecmascript instead of including them per dependency. A decision was made to have a unique
wp-polyfill script you can depend on and use all the polyfills made available by WordPress. This script would include both ECMAScript polyfills and also different Web Standards that require polyfills such as
element.closest. This results in a better developer experience as it’s not always easy to know what polyfill is needed for per script.