PNPM 7.15+ is no longer defaulting to --strict-peer-dependencies

[elliot-nelson]

pnpm version: 7.17.1

Code to reproduce the issue:

npm install -g pnpm@7.17.1
mkdir temp && cd temp
npm init -y
npm install @rushstack/heft-jest-plugin
pnpm install

Expected behavior:

 ERR_PNPM_PEER_DEP_ISSUES  Unmet peer dependencies

.
└─┬ @rushstack/heft-jest-plugin 0.4.0
  └── ✕ missing peer @rushstack/heft@^0.48.8
Peer dependencies that should be installed:
  @rushstack/heft@^0.48.8  

(This expected behavior occurs as recently as pnpm 7.13; broken in 7.15)

Actual behavior:

 WARN  Issues with peer dependencies found
.
└─┬ @rushstack/heft-jest-plugin 0.4.0
  └── ✕ missing peer @rushstack/heft@^0.48.8
Peer dependencies that should be installed:
  @rushstack/heft@^0.48.8  

Additional information:

• node -v prints: v16.15.0
• Windows, macOS, or Linux?: macOS

[octogonz]

@zkochan was this an intentional change?

@elliot-nelson observed that strict-peer-dependencies defaults to true from version 7.0.0 through 7.13.x but seems to have reverted to the old default as of 7.15.x. That's a fairly significant change for a SemVer minor release.

[zkochan]

I don't think it's a breaking change because it removes errors. Vice versa would be a breaking change.

[octogonz]

Looks like it was actually introduced in a patch release:

7.13.5

Patch Changes

• Print a warning when cannot read the builtin npm configuration.
• Also include missing deeply linked workspace packages at headless installation #5034.
• pnpm outdated should work when the package tarballs are hosted on a domain that differs from the registry's domain #5492.
• strict-peer-dependencies is set to false by default. 👈👈👈

[octogonz]

I don't think it's a breaking change because it removes errors. Vice versa would be a breaking change.

A couple counterpoints:

1. For people who enable strict-peer-dependencies, it performs important validation. Having it silently disabled allows problems to creep into your lockfile, which may take a while to discover, and then could be fairly expensive to reverse.

2. The PNPM CLI acts as a sort of interface contract for Rush. Apparently a while ago when someone found that --strict-peer-dependencies was enabled by default, they changed the Rush code to rely on this assumption. Take a look at PR [rush] Fix --strict-peer-dependencies for PNPM >= 7.0.0 microsoft/rushstack#3395 which introduced this logic:

if (semver.gte(this.rushConfiguration.packageManagerToolVersion, '7.0.0')) {
  // pnpm >= 7.0.0 handles peer dependencies strict by default
  if (this.rushConfiguration.pnpmOptions.strictPeerDependencies === false) {
    args.push('--no-strict-peer-dependencies');
  }
} else {
  // pnpm < 7.0.0 does not handle peer dependencies strict by default
  if (this.rushConfiguration.pnpmOptions.strictPeerDependencies) {
    args.push('--strict-peer-dependencies');
  }
}

[zkochan]

I am sorry that this caused problems on your end and it was confusing but there was no other way. There was a storm of issues about these errors. Also, lots of angry tweets. Lots of messages in the discord chatrooms. And questions on stackoverflow. Turning the setting off was the only way out. And up to this point nobody complained about it.

[octogonz]

I understand. That makes sense. Perhaps it could have been a larger version bump?

In any case, Rush should probably change its logic to explicitly set all the important options to avoid relying on assumptions about defaults.

[zkochan]

It could be a larger bump. It just felt like a bug fix because it removes errors.

[octogonz]

Closing the issue, since this behavior is "by design", and there's nothing else we can do at this point.

We will update Rush's logic instead.

[octogonz]

Fixed in microsoft/rushstack#3828