Implement NPM 7+ w/ Workspaces

[chrisdholt]

#4737 was initially tracked as an investigation into whether or not we should move towards NPM 7+, a newer version of Yarn, or continue on with Yarn + Lerna. The issue has now been closed with updates to the FAST Tooling repository which served as a small test bed.

The results of the investigation show that NPM 7+ is likely the best approach for our mono repository given our current requirements. This issue exists as notification that we are beginning to implement this.

[radium-v]

We should check out Lage as a replacement for workspace running: https://microsoft.github.io/lage/

[radium-v]

So I spent some time this weekend looking into lage and learned:

• it's Norwegian for "make", pronounced "law-geh"
• the documentation is incomplete, but once I understood the pipeline config it started to come together a little better
• It seems to collide with the lerna.json config file, with regards to the packages it sees
• caching makes prepare go vroom (after the first run)
• we can be more efficient with the clean/build parts and normalize them across packages for consistency, independent of the tool
• building all (most) packages is quick with parallelization, excusing the webpack-based ones (and docusaurus)
• it comes with the ability to upload cache objects to remote locations, so devs could download the cached builds instead of running prepare locally

One thing we lose with Lerna is the ability to keep the workspaces separated from the packages. Right now, when we run yarn prepare or yarn lerna run test --stream, it only operates on a subset of packages; the packages listed in lerna.json and those in the root package.json differ, so that Yarn can install dependencies for all packages but Lerna only builds and tests in some.

Lerna's packages list:

• packages/**/*
• sites/fast-color-explorer
• sites/fast-component-explorer
• sites/fast-website

Workspaces packages list:

• packages/**/*
• sites/fast-color-explorer
• sites/fast-component-explorer
• sites/site-utilities
• sites/fast-website
• sites/website
• examples/design-system-tutorial

Ideally, we'd either have every package explicitly listed in the package.json config, or use wildcards that cover all packages. Either way, changing the list would cause all packages in the project to build on every prepare (namely the docusaurus website, and the node-based examples).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[awentzel]

Already using workspaces organized according to existing package goals.