Update webpack globally

[gravityrail]

We previously updated to webpack 5, plus the latest @automattic/calypso-build (v9.0.0) for Jetpack. This applies those same version updates, plus the latest webpack-cli, to all the places where we use them.

Changes proposed in this Pull Request:

• Update all projects to latest webpack, webpack-cli and calypso-build

Jetpack product discussion

p1629397551142600-slack-jetpack-crew

Does this pull request change what data or activity we track or use?

No

Testing instructions:

Nothing should change, though we may get a few new deprecation warnings.

[matticbot]

Caution: This PR has changes that must be merged to WordPress.com
Hello gravityrail! These changes need to be synced to WordPress.com - If you 're an a11n, please commandeer and confirm D65812-code works as expected before merging this PR. Once this PR is merged, please commit the changes to WP.com. Thank you!
This revision will be updated with each commit to this PR

[test-case-reminder]

Here are some suggested test cases for this PR.

Connection

• In-place connection with free plan
• In-place connection with paid plan
• In-place connection with product purchase
• Classic connection. Use Safari, or set a constant JETPACK_SHOULD_NOT_USE_CONNECTION_IFRAME to true
• Disconnect/reconnect connection
• Secondary user connection
• Connection on multisite

Verify that the changes are compatible with the plugins that use the connection package.

• WooCommerce Payments
• Jetpack Boost
• Previous versions of Jetpack

If you think that suggestions should be improved please edit the configuration file here. You can also modify/add test-suites to be used in the configuration file.

[github-actions]

Thank you for your PR!

When contributing to Jetpack, we have a few suggestions that can help us test and review your patch:

• ✅ Include a description of your PR changes.
  
• ✅ All commits were linted before commit.
  
• ✅ Add a "[Status]" label (In Progress, Needs Team Review, ...).
  
• ✅ Add testing instructions.
  
• ✅ Specify whether this PR includes any changes to data or privacy.
  
• ✅ Add changelog entries to affected projects
  

This comment will be updated as you work on your PR and make changes. If you think that some of those checks are not needed for your PR, please explain why you think so. Thanks for cooperation 🤖

---

The e2e test report can be found here. Please note that it can take a few minutes after the e2e tests checks are complete for the report to be available.

---

Once your PR is ready for review, check one last time that all required checks (other than "Required review") appearing at the bottom of this PR are passing or skipped.
Then, add the "[Status] Needs Team review" label and ask someone from your team review the code.
Once you’ve done so, switch to the "[Status] Needs Review" label; someone from Jetpack Crew will then review this PR and merge it to be included in the next Jetpack release.

---

Jetpack plugin:

• Next scheduled release: September 7, 2021.
• Scheduled code freeze: August 30, 2021.

---

Backup plugin:

• Next scheduled release: September 7, 2021.
• Scheduled code freeze: August 30, 2021.

[retrofox]

sorry I was taking a look at the PR and changed the title accidentally :-(

[anomiex]

Looks sensible to me. I fixed lazy-images to continue using calypso-build, see a72fa61 for an explanation of what was breaking there.

[gravityrail]

@anomiex thanks for the patch. Unfortunately it broke es5 validation for the built lazy-images package.

 > @ validate-es5 /home/runner/work/jetpack/jetpack/projects/packages/lazy-images
  > eslint --parser-options=ecmaVersion:5 --no-eslintrc --no-ignore "./dist/"
  
  
  /home/runner/work/jetpack/jetpack/projects/packages/lazy-images/dist/intersection-observer.js
    1:3  error  Parsing error: Unexpected token )
  
  /home/runner/work/jetpack/jetpack/projects/packages/lazy-images/dist/lazy-images.js
    1:3  error  Parsing error: Unexpected token )

I'll jump in and fix this, since I already fixed it previously.

[anomiex]

I'll jump in and fix this, since I already fixed it previously.

Oops, I already did before I saw your comment.

[gravityrail]

@anomiex I reverted the change to es9 validation since it emits code that won't run in some browsers. Better to just emit es2015 as before, just in case. If we want to make a change to which browsers we support it should probably happen in a different PR.

[anomiex]

We already did drop support for IE11. p1HpG7-c8n-p2

[gravityrail]

If it's cool with everyone else to update browser compat for this library in this PR then I'm fine with that. I just didn't want to introduce accidental/unexpected breakage outside the scope of the change. But if it's not going to break anything then let's go es9!

[anomiex]

Actually... I don't have any idea what calypso-build is doing, but just adding the

       "browserslist": [
               "extends @wordpress/browserslist-config"
       ],

bit (and the dep on @wordpress/browserslist-config) is somehow enough to restore IE11 support when I build locally. All the other stuff you added in 9b17538 seems unnecessary.

I have no idea what's going on with that, since @wordpress/browserslist-config 4.1.0 doesn't include IE11 so if anything I'd think it should be the opposite.

[gravityrail]

Good catch. I'm not at my computer right now so if you want to revert my change and add browserlist back in go right ahead, otherwise I'll take a look later or tomorrow.

…

On Mon, Aug 23, 2021, 2:06 PM Brad Jorsch ***@***.***> wrote: Actually... I don't have any idea what calypso-build is doing, but just adding the "browserslist": [ "extends @wordpress/browserslist-config" ], bit (and the dep on @wordpress/browserslist-config) is somehow enough to restore IE11 support when I build locally. All the other stuff you added in 9b17538 <9b17538> seems unnecessary. I have no idea what's going on with that, since @wordpress/browserslist-config 4.1.0 doesn't include IE11 so if anything I'd think it should be the opposite. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#20789 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAMVOGHIUTIE6NFERKMXSTT6KZ4PANCNFSM5CSNP7UQ> .

[anomiex]

OK, I see what's going on now.

• The source files are written in ES5 (which is left over from before we added transpilation via calypso-build in Lazy Images: Use calypso-build to build #17571). Babel doesn't "upgrade" any of the syntax to later versions, so the syntax remains ES5.
• @wordpress/browserslist-config 4.1.0 includes "op_mini all". This triggers webpack to not use arrow functions in its own boilerplate.

Thus the output winds up compatible with ES5, so the validate-es5 check passes.

But the "op_mini all" is apparently ignored by Babel, so if we were to update the source files (which we probably should do one of these days now that we use calypso-build) the validate-es5 check would no longer pass.

What we really need to do is to figure out how to make a validate check that uses the browserslist targets instead of just guessing at an appropriate ES parser level. See p9dueE-3fG-p2 for more on that topic.

EDIT: "op_mini all" is included via "> 1%", as the caniuse data currently has it at 1.08%.

[anomiex]

Turning off auto-merge to get review of my own change to the PR.

[gravityrail]

Looks great @anomiex - thanks for getting to the bottom of it. I did think a few times "how the hell did this ever work, and how does that other thing still work, and..." but you managed to get to the bottom of it with that op_mini thing.

[github-actions]

Great news! One last step: head over to your WordPress.com diff, D65812-code, and commit it.
Once you've done so, come back to this PR and add a comment with your changeset ID.

Thank you!

[anomiex]

r230707-wpcom