[Build] Revisit polyfill strategy

[jtoar]

This PR

1. bumps the version of Node.js Redwood's build process targets from 12.x to 14.x, and
2. reduces the number of polyfills (specifically on the api side) by using the babel-plugin-polyfill-corejs3 usage-pure strategy explicitly (99% of the changes are due to this)

Note

This PR builds on #6208.

When I started this working on this, it was just to bump the Node.js version Redwood targets from 12.x to 14.x. This took about two minutes, but I looked at the changes in .redwood/prebuild, and while the syntax transformations took effect (Bbael left ?? alone) none of the polyfills were gone, even though things like String.prototype.matchAll were in Node.js 14. So I did some digging.

Right now, we polyfill the kitchen sink. The strategy we use, plugin-transform-runtime, doesn't take the version of Node.js we target into account. It just polyfills as much as it can, including the the trivial methods that have been in Node.js since v0.11.0 like Array.prototype.forEach. Note that I'm mainly talking about the api side. The web side actually does take the target into account because it uses a different polyfill strategy, but we target a lot of browsers.

Babel's been rethinking their polyfill story and there's a newish (it's been around for a while actually, and is used under-the-hood of the one we already use, just without the customizations we need) plugin we can leverage: babel-plugin-polyfill-corejs3. This plugin takes the Node.js target into account, and if we use the usage-pure strategy, 1) doesn't polyfill things we don't use and 2) polyfill in a pure (i.e. doesn't pollute the global scope by doing an "effectful" import) way.

babel-plugin-polyfill-corejs3's usage-pure strategy isn't perfect. For example, it's not detecting that Promise.any needs to be polyfilled. The solution to this is to use the includes option to completely polyfill a few builtins (which is what we're doing now, just for everything instead of for a curated few). We just have to keep track of them.

Also, the api side was pinned to core-js 3. It's a best practice to pin it to the minor version of core-js, not the major. But if we do that, we're going to polyfill a lot more proposals (cause we have proposals set to true). See the end of this comment #6208.

Further reading:

• https://github.com/babel/rfcs/blob/main/rfcs/0001-rethink-polyfilling-story.md
• https://github.com/babel/rfcs/blob/main/rfcs/0002-top-level-targets.md
• https://github.com/babel/rfcs/blob/main/rfcs/0003-top-level-assumptions.md

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit 6f69b74. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this branch

---

✅ Successfully ran 14 targets

• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run test --concurrency 2 -- --colors --maxWorkers 2
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build
• cli run build

---

Sent with 💌 from NxCloud.

[netlify]

✅ Deploy Preview for redwoodjs-docs canceled.

Name	Link
🔨 Latest commit	6f69b74
🔍 Latest deploy log	https://app.netlify.com/sites/redwoodjs-docs/deploys/62fe050accf8e100089f1ff8

[jtoar]

There's more we could probably do here, but it hasn't been my main focus. For docs on this one see https://babeljs.io/docs/en/assumptions#enumerablemodulemeta

[jtoar]

I still have to scan our packages to see if we're using a lot of proposals, but I don't think we are. Regardless, we have to make a decision if we want to use them because it opens the door to a lot of Stage 0-2 features that could change/get dropped. shippedProposals is a nice compromise because it allows using proposals that are Stage 4+. And we could always just include the proposals we want to use in an explicit includes array, so it's not all or nothing.

[jtoar]

I need to double check a few things, but I want to get deploy-target CI testing this one before getting sinking more time into this. I'm going to merge this and then I'll revert it later if deploy target CI blows up, but regardless I'll follow up with a PR that cleans up a few things.

[jtoar]

See #7712.