We always want to prefer a headless install and require explicit action
update the lockfiles. pnpm supports CLI arguments set in npmrc files, so
we set [frozen-lockfile](https://pnpm.io/cli/install#--frozen-lockfile)
to true, which will make the default install experience error out when a
lockfile update is needed. Users can pass --no-frozen-lockfile to
override and update the lockfile.
This PR adds [the
CLI](https://github.com/arethetypeswrong/arethetypeswrong.github.io/tree/main/packages/cli)
from <https://arethetypeswrong.github.io> to our client packages and
adds a script that runs it against the package. The check is slow
because it packs the package first and runs on the packed contents.
Because the check is slow, it does not run automatically during local
builds but can be triggered manually. In CI the checks run as a test
since they rely on the build output. Ideally this check would be done in
the "pack" phase since we are already packing packages there and could
run on the packed content directly. But that is a bigger CI-centric
change, so I opted not to do that right now.
There are several azure projects that are [producing invalid ESM
types](https://github.com/arethetypeswrong/arethetypeswrong.github.io/blob/main/docs/problems/FalseCJS.md).
Those failures are ignored for now using .attw.json config files in the
individual projects - they'll be cleaned up as we fix the types/exports
field for those packages.
This PR also removes the exports field from most packages, so that we
can re-enable exports in a controlled fashion, while being protected
from releasing bad types by attw.
We currently use lerna in some places in CI, but it is called via npx
and thus its dependencies are not locked to a particular version., This
means that lerna releases can break our pipelines. This PR adds lerna as
a root dependency to the server release groups, so that it and its
dependencies versions are pinned.
Despite the fact that lerna is still installed, I updated the scripts of
the release groups to use pnpm -r run instead of lerna. That reduces the
use of lerna so it will be easier to remove once we can.
## Description
pnpm v8 introduces a new lockfile format, but v7 can produce that
lockfile format to make it easier to move to pnpm 8. This change adds a
setting to the .npmrc file for each package and release group to use the
v6 lockfile format (which is admittedly confusing since v8 is the pnpm
version in which it becomes the default).
Unfortunately, testing has revealed that pnpm 8 will still make lockfile
changes in packages/workspaces that use peer dependencies, even when
using the v6 lockfile format. This is unfortunate, but only affects the
client release group.
To update I used the following commands:
```shell
pnpm exec flub exec -a --releaseGroupRoots -- "echo '# Use pnpm v8 lockfile format\nuse-lockfile-v6=true' >> .npmrc"
pnpm exec flub exec -a --releaseGroupRoots -- "pnpm i"
```
This PR changes the client release group to use pnpm instead of npm.
lerna now uses the pnpm workspace config and uses pnpm to execute
scripts.
## Things that should still work
Note: `fluid-build` === `npm run build:fast`
- fluid-build should continue to build the repo incrementally.
- `fluid-build --install` should use pnpm for the release groups that
use it and npm elsewhere.
- You can still use npm to run scripts, e.g. `npm run build`, or you can
switch to pnpm e.g. `pnpm build`.
Co-authored-by: Rishhi Balakrishnan <107130183+RishhiB@users.noreply.github.com>
Reviving #10847.
Enforce that the version of node used is at least 14.13.0 (released on
2020-09-29), which according to
https://www.the-guild.dev/blog/support-nodejs-esm means it should
support ESM. This uses the mechanism documented in
https://docs.npmjs.com/cli/v8/configuring-npm/package-json#engines.
This produces an error when running `npm i` in the root if using an
older version of node.
Note that the 14 branch of node is the oldest supported branch (see
https://nodejs.org/en/about/releases/), no one should be one node older
than 14, so updating to at least 14.13.0 should be a non-breaking
change.
Additionally, our `.nvmrc` file specifies node 14, and our readme says
to use that version.
Since this is in the root package.json, not one we ship to users, it
should have no impact on consumers of our packages.
## Example Error
If I force requiring version 15 instead (so my system errors) the error
looks like:
```
$ npm i
npm ERR! code ENOTSUP
npm ERR! notsup Unsupported engine for root@0.14.0: wanted: {"node":">=15.13.0"} (current: {"node":"14.19.3","npm":"6.14.17"})
npm ERR! notsup Not compatible with your version of node/npm: root@0.14.0
npm ERR! notsup Not compatible with your version of node/npm: root@0.14.0
npm ERR! notsup Required: {"node":">=15.13.0"}
npm ERR! notsup Actual: {"npm":"6.14.17","node":"14.19.3"}
```
I have confirmed `npm ci` also produces this error.
The packages can be built locally via npm scripts at the root. server/routerlicious will use docker to build the packages as well (on top of composing the server)
Also moved shared/test-utils and shared/tools-core to server as they are only used by the server.
packages/server will eventually move out in the future when we are ready to independently rev the versions
Tyler Butler
Curtis Man
Daniel Lehenbauer
sumedhb1995
Kurt Berglund
Wes Carlson