I've created this NX workspace with some libraries which are published to NPM and github.
The following state of the repository causes the following error on installation
npm i @mintplayer/ng-json-ld
npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR!
npm ERR! While resolving: client-app@0.0.0
npm ERR! Found: @angular/common@16.2.2
npm ERR! node_modules/@angular/common
npm ERR! @angular/common@"~16.2.0" from the root project
npm ERR! peer @angular/common@"^16.0.0" from @mintplayer/ng-json-ld@16.2.0
npm ERR! node_modules/@mintplayer/ng-json-ld
npm ERR! @mintplayer/ng-json-ld@"*" from the root project
npm ERR! 1 more (@angular/platform-browser)
npm ERR!
npm ERR! Could not resolve dependency:
npm ERR! peer @angular/common@"16.2.1" from @angular/router@16.2.1
npm ERR! node_modules/@angular/router
npm ERR! peer @angular/router@"16.2.1" from @mintplayer/ng-json-ld@16.2.0
npm ERR! node_modules/@mintplayer/ng-json-ld
npm ERR! @mintplayer/ng-json-ld@"*" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.
npm ERR!
npm ERR!
npm ERR! For a full report see:
npm ERR! C:\Users\Pieterjan De Clippel\AppData\Local\npm-cache\_logs\2023-08-26T17_45_08_268Z-eresolve-report.txt
npm ERR! A complete log of this run can be found in:
npm ERR! C:\Users\Pieterjan De Clippel\AppData\Local\npm-cache\_logs\2023-08-26T17_45_08_268Z-debug-0.log
package.json
"peerDependencies": {
"@angular/common": "^16.0.0",
"@angular/core": "^16.0.0",
"@angular/platform-browser": "^16.0.0",
"rxjs": "^7.8.0"
},
This turns out to be the culprit.
I added the @angular/router
as a peerDependency, and now I can install the package without problems
"peerDependencies": {
"@angular/common": "^16.0.0",
"@angular/core": "^16.0.0",
"@angular/router": "^16.0.0", // <-- explicitly added this
"@angular/platform-browser": "^16.0.0",
"rxjs": "^7.8.0"
}
@angular/router
isn't used anywhere in the code. However somewhere in a specfile I need to use it. And if I don't range the version in the packagefile (^ x.x.x
) I get the above error, even though I don't use the package in code, only in unit-tests.
These problems have been biting me several times. Is there a way I can prevent these imports in my libraries if the corresponding package.json
doesn't yet contain the dependency?
Similar discussions:
I'm getting the impression I have to use a feature called enforce-module-boundaries, but I don't know yet how.