Upgrade to node v.16+

[laurkim]

Polaris react uses node v12.22.0.
According to the below message that surfaces whenever you run dev up, we should upgrade this soon.
This will probably apply for our other repos as well.

Node v12.22.0 (as specified in dev.yml) does not work on the new Macs with
Apple Silicon. Since Tobi has said we'll be replacing all our Macs with ones
running on Apple Silicon, it is imperative that this project update its node
version to v16.0.0+. Onboarding will very soon start handing out Apple
Silicon Macs, at which point this project would not be bootable by new
Shopifolk without a node update. Soon, we'll be enforcing the node upgrade
through dev regardless of architecture, to make sure all projects are ready
for Apple Silicon.

Please take time to update node before it becomes forced.

👋 Thanks for opening your first issue. A contributor should give feedback soon. If you haven’t already, please check out the contributing guidelines.

[laurkim]

fyi: bumping node in web issue and related PR

[BPScott]

Collating a few thoughts on library versioning that I've had elsewhere:

My general approach for packages that web-foundations maintains has been:

• Support all LTS versions of node till get marked as end-of-life by node per their support timelines (atm this is v12 / v14 / v16). At a minimum this be the first minor version that was marked as LTS (e.g. for 12.13.0 was the first v12 LTS release), but it is ok to bump that up if you really want some features that were added in a later version (e.g. loom wants 12.22.0 as that's when esmodules support was marked as stable)
• Specify your support range by having an engines field in package.json that denotes the node versions supported. Yarn will refuse to install the package on node versions that don't match this constraint.
• Compile targetting those node versions.
• Locally develop with run the oldest version of node that you support - this will makes sure you don't accidentally use an API that was added between "the node version you say to support" and "the node version you're running against (less of an issue for polaris as it targets the browser)
• Run CI against the minimum supported version of node for each LTS version (i.e. 12/14/16) - this helps with the above rational for helping ensure you don't accidentally use APIs that are only present in some versions of the platforms you support.

The push for using node 16 locally thanks to the move to M1 powered laptops, should not affect our support overall - prematurely leaving folks using node v12/v14 in production behind and making them update their node version to continue with polaris support feels harsh. With that in mind, we can get through this update by maintaining the versions we currently support, but adjusting what we run locally. This has the bonus of not needing a breaking change.

• Update dev.yml and .nvmrc to use v16.13.0 (the first LTS release in the v16 line). To use v16 locally.
• Update CI to run against the oldest supported node version - 12.20, 14.x, and 16.x using build matrixes, you'll also need to update shipit.yml to account for the new action names. Now that we're not running "the oldest supported node version" locally that puts the responsibility of ensuring we're not using any unsupported APIs onto CI.

See Shopify/quilt#2063 / Shopify/quilt#2066 for a demo of how this went down in quilt. https://github.com/Shopify/loom/pull/304 is a demo of converting loom's CI to test against a single node version to using a matrix

[alex-page]

Thanks @BPScott. One thing I want to share is that the Polaris library is focused on supporting our main internal product. We can't be expected to make a great design system for external and internal users right now. This means that consumers might get more breaking changes as we make this the best library for that product.

I don't see a large risk in a creating a breaking change for node v16 and dropping support for older versions. If that is what our internal product is also doing. Simplification is also super important and supporting multiple versions does not help us with that vision long term.

[aaronccasanova]

@laurkim @kyledurand Can we close this issue now that PR #4778 is merged?

[BPScott]

dev up works in the v8 and v9 branches thanks to #4778, however it continues to fail on the main branch, which feels pretty user-hostile.

[kyledurand]

dev up works on main now #4888