[abd1rahmane]

Installing @loopback/core@8 and an extension in the same tree fails with ERESOLVE because the published manifests still declare peerDependencies on the previous major. The 7.0.0 and 8.0.0 releases bumped the version, the dependencies and the devDependencies of each package, but the peer ranges were left pointing at the old version. 29 packages ended up tested against a version they do not accept.

This updates the 54 internal peer ranges that excluded the version their target package now has. Each one moves to the caret range of the current major of that package, for example @loopback/core ^7.0.0 becomes ^8.0.0 and @loopback/rest ^15.0.1 becomes ^16.0.0, which is the same form the workspace dependencies already use.

The drift has no test that catches it, because the monorepo resolves workspace packages by path and never evaluates the ranges it publishes. bin/check-peer-deps.js reads every workspace manifest and reports any internal peer range that does not accept the target version. It uses only Node built-ins, it runs from check-package-metadata, which the CI workflow already calls, and it is also available as npm run check-peer-deps so contributors can run it before pushing.

Reproduction of the defect on the current published packages:

npm install @loopback/core@^8.0.0
npm install @loopback/authentication@^13.0.0
npm error Could not resolve dependency:
npm error peer @loopback/core@"^7.0.0" from @loopback/[email protected]

After the change, packing @loopback/core, @loopback/rest, @loopback/authentication and @loopback/security from this branch and installing the four tarballs in an empty project resolves without an error. node bin/check-peer-deps.js reports every range as accepted, and prettier passes on the changed files.

I did not run the full npm test locally, it needs the full npm ci of the monorepo, so the CI run on this PR is the check for the build and the test suites. The commit is signed off under the DCO.

Fixes #11901
Full suite result on this branch: 4498 passing, 40 pending, 218 failing. Every failure is in packages/cli integration tests, where the yeoman generators need a terminal for their prompts and scaffold apps in temporary directories. The signatures are The stdin is not a terminal. No prompt is allowed. and 60 second timeouts in app.integration.js, repository.integration.js, extension.integration.js and the relation generators, followed by Workerpool Worker terminated Unexpectedly. The suite also ends with exit code 0 despite those failures, so the counts come from the log and not from the exit status.

I ran the same file, packages/cli/test/integration/generators/app.integration.js, on unmodified master: 25 passing, 1 pending, 24 failing, same timeout signature. The failures predate this change and none of them touch a peer range.