Description
@sourceloop/audit-log declares @sourceloop/core as a peerDependency. In
consumer monorepos where @sourceloop/core is a local workspace package
(for example loopback4-microservice-catalog, where node_modules/@sourceloop/core
is a symlink to packages/core), npm cannot reconcile that peer during tree
re-resolution and fails with ERESOLVE.
The practical impact is that npm audit fix cannot run at all in those
consumers — it aborts before applying any remediation, so security fixes cannot
be applied through the normal workflow.
npm error code ERESOLVE
npm error While resolving: @sourceloop/audit-log@10.0.1
npm error Found: peer @sourceloop/core@"^21.0.0" from @sourceloop/audit-log@10.0.1
npm error Conflicting peer dependency: @sourceloop/core@21.0.0
npm error node_modules/@sourceloop/core
When this started
The peer was introduced in 9.1.0. Every release up to and including 9.0.0
declared no peerDependencies at all:
| Version |
@sourceloop/core peer |
| 6.0.0 – 9.0.0 |
none |
| 9.1.0 |
^20.0.6 (first appearance) |
| 10.0.0 |
^20.0.6 |
| 10.0.1 |
^21.0.0 |
Consumers pinned to ^9.0.0 picked this up silently with no commit of their
own, as soon as 9.1.0 was published.
Diagnosis
The peer range itself is correct — the workspace @sourceloop/core is 21.0.0
and satisfies ^21.0.0. The failure is in npm's resolution of a registry
package's peer against a workspace-linked package, not a version mismatch.
Verified during investigation:
- a plain
npm install --package-lock-only in the consumer succeeds, so the
existing tree is valid; only re-resolution fails
overrides pinning the peer from the consumer side does not helpnpm audit fix --legacy-peer-deps works, but disables peer validation for the
entire install
A controlled A/B test isolated the cause. Two tarballs identical except for the
peer metadata were installed into the consumer:
| Variant |
Result |
peerDependenciesMeta.@sourceloop/core.optional = true |
ERESOLVE gone, fix plan produced |
| identical tarball, flag absent |
ERESOLVE persists |
Acceptance criteria
Description
@sourceloop/audit-logdeclares@sourceloop/coreas apeerDependency. Inconsumer monorepos where
@sourceloop/coreis a local workspace package(for example
loopback4-microservice-catalog, wherenode_modules/@sourceloop/coreis a symlink to
packages/core), npm cannot reconcile that peer during treere-resolution and fails with
ERESOLVE.The practical impact is that
npm audit fixcannot run at all in thoseconsumers — it aborts before applying any remediation, so security fixes cannot
be applied through the normal workflow.
When this started
The peer was introduced in 9.1.0. Every release up to and including 9.0.0
declared no
peerDependenciesat all:@sourceloop/corepeer^20.0.6(first appearance)^20.0.6^21.0.0Consumers pinned to
^9.0.0picked this up silently with no commit of theirown, as soon as 9.1.0 was published.
Diagnosis
The peer range itself is correct — the workspace
@sourceloop/coreis21.0.0and satisfies
^21.0.0. The failure is in npm's resolution of a registrypackage's peer against a workspace-linked package, not a version mismatch.
Verified during investigation:
npm install --package-lock-onlyin the consumer succeeds, so theexisting tree is valid; only re-resolution fails
overridespinning the peer from the consumer side does not helpnpm audit fix --legacy-peer-depsworks, but disables peer validation for theentire install
A controlled A/B test isolated the cause. Two tarballs identical except for the
peer metadata were installed into the consumer:
peerDependenciesMeta.@sourceloop/core.optional = trueAcceptance criteria
npm audit fixruns to completion inloopback4-microservice-catalogwithout--legacy-peer-deps