FluidFramework/.npmrc

engine-strict=true
frozen-lockfile=true
strict-peer-dependencies=true

# Disable pnpm update notifications since we use corepack to install package managers
update-notifier=false
# Don't use new lockfile format because component governance does not yet support it
use-lockfile-v6=false
# Use the number of cores on the machine by default.
workspace-concurrency=0

# Hoist these dependencies to the root workspace
public-hoist-pattern[]=@arethetypeswrong/cli
# ['*eslint*', '*prettier*'] is the default, so we add those as well
public-hoist-pattern[]=*eslint*
public-hoist-pattern[]=*prettier*
build: Require at least node >=14.13.0 and npm ^6 (#12922) 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. 2022-11-15 05:53:56 +03:00			`engine-strict=true`
build: Set prefer-frozen-lockfile=true in all .npmrc files (#21922) 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. 2024-07-17 04:19:41 +03:00			`frozen-lockfile=true`
build(client): Set strict-peer-dependencies=true (#14806) We don't have any peer dependency violations in client now, so we can enable strict peer dependencies. 2023-03-29 20:07:12 +03:00			`strict-peer-dependencies=true`
build: Disable pnpm update checks (#14956) 2023-04-05 03:02:24 +03:00
			`# Disable pnpm update notifications since we use corepack to install package managers`
			`update-notifier=false`
build: Revert to older pnpm lockfile format (#16082) This reverts the changes made in #15377, going back to the older pnpm lockfile format. This is needed because component governance doesn't yet work on the new lockfile. Fixes [AB#4675](https://dev.azure.com/fluidframework/235294da-091d-4c29-84fc-cdfc3d90890b/_workitems/edit/4675). 2023-06-20 22:30:59 +03:00			`# Don't use new lockfile format because component governance does not yet support it`
			`use-lockfile-v6=false`
build: Limit use of lerna in server CI pipelines (#16052) 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. 2023-08-18 03:39:03 +03:00			`# Use the number of cores on the machine by default.`
			`workspace-concurrency=0`
build(client): Add are-the-types-wrong check to client packages (#18650) 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. 2023-12-06 04:48:06 +03:00
			`# Hoist these dependencies to the root workspace`
			`public-hoist-pattern[]=@arethetypeswrong/cli`
			`# ['eslint', 'prettier'] is the default, so we add those as well`
			`public-hoist-pattern[]=eslint`
			`public-hoist-pattern[]=prettier`