This repository has been archived by the owner on Feb 23, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 219
Build: Fix errors related to WP5.8-beta2 updates and drop IE11 support. #4362
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This surfaced with the build process changes. Likely any polyfills added by WebPack covered over the problem.
nerrad
added
priority: high
The issue/PR is high priority—it affects lots of customers substantially, but not critically.
type: bug
The issue/PR concerns a confirmed bug.
tools
Used for work on build or release tools.
labels
Jun 16, 2021
Size Change: -72 kB (-7%) ✅ Total Size: 919 kB
ℹ️ View Unchanged
|
Is this PR still needed? |
It's no longer needed to address any errors, but the performance gains from dropping IE11 support in our builds would be nice. |
This PR has been marked as If deemed still relevant, the pr can be kept active by ensuring it's up to date with the main branch and removing the stale label - otherwise it will automatically be closed after 10 days. |
github-actions
bot
added
the
status: stale
Stale issues and PRs have had no updates for 60 days.
label
Nov 10, 2021
nerrad
removed
the
status: stale
Stale issues and PRs have had no updates for 60 days.
label
Nov 19, 2021
I extracted the IE11 stuff into an updated PR here #5212 |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
priority: high
The issue/PR is high priority—it affects lots of customers substantially, but not critically.
tools
Used for work on build or release tools.
type: bug
The issue/PR concerns a confirmed bug.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After updating to WordPress 5.8-beta2, we noticed that all our builds were breaking in the browser with an error containing something like this (variations of actual text, but all referencing undefined 'mark'):
This can be traced to a missing polyfill as a result of this change in WP core for the WP 5.8 branch.
While there are some efforts to restore this polyfill in WordPress(which will likely negate the urgency of this Pull Request), I'm still publishing this as something that we'll want to work on anyways (and we can decide whether it needs to go in the Woo Core 5.5 release as a part of Woo Blocks 5.3 branch depending on the outcome of the WP core changes and if there are any other polyfill related issues).
Unfortunately, at the moment I can't own the completion of this work, so I've pushed this in progress PR which functionally fixes all the issues by:
@wordpress/babel-preset-default
in our Webpack configuration and removing async generator.Also:
@wordpress/browserlist-config
settings are.I've tested this on WP 5.8-beta2 and WP 5.7.2 and things seem to work okay but note that the Stripe Extension and WooCommerce Payments are affected by this bug, so if you have either of those active you will still experience similar errors in the checkout/cart blocks.
Next Steps
@wordpress/babel-preset-default
. We might just need to keep the prop-types removal plugin (and maybe the class properties one, but should check if that's only needed for IE11 support...) for production builds.I haven't checked whether our automated test suite fails or not related to this. So any fixes in test builds will need addressed.(they pass)