Unable to install on node 16

Can’t install ts-loader with node 16.

Expected Behaviour

Install should be successful in ts-loader repository with node 16.

Actual Behaviour

node 16 install fails in ts-loader repository with the following output

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: ts-loader@9.3.0
npm ERR! Found: webpack@5.37.1
npm ERR! node_modules/webpack
npm ERR!   dev webpack@"^5.20.0" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer webpack@"2 || 3" from babel-loader@7.1.2
npm ERR! node_modules/babel-loader
npm ERR!   dev babel-loader@"^7.0.0" 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.

Steps to Reproduce the Problem

I used v16.15.0 (npm v8.5.5) but you can use any version of node 16.

1. Go into ts-loader repository
2. Run npm i
3. You’ll quickly see the above error output

Location of a Minimal Repository that Demonstrates the Issue.

This repository.

[arcanis]

For clarity, we enforce dependencies (so that packages can only access the dependencies they declare), because there’s no guarantee as to what would happen otherwise. Pnpm does it as well, but npm (even its latest releases) doesn’t.

Peer dependencies, on the other hand, have a quite different semantic: they only guarantee that a package will get access to the exact same instance of its declared peer dependencies as what its parent the dependency tree provided. Optionally, they also check that the provided versions match specific semver ranges, but that’s secondary (that’s what I was referring to by saying “it’s just a hint”: the range is only a check, and doesn’t contribute to the version resolution).

Npm 7 changed the way peer dependencies worked so that if you fulfill a peer dependency with an invalid package (for example providing react@18 to a package whose react peer dependency is ^17), it crashes (the ERESOLVE error in the OP). This behaviour is unique to them, and that’s what I was referring to when I said we had no plan to change peer dependencies 🙂

[arcanis]

yarn@3 are moving to that model

Just for the record, no, we are not. Peer dependencies ranges have always been a hint, have worked just fine in Yarn, and we have no plan to change them (whether it’s to abort on “invalid” peer dependency versions, or auto-install peer dependencies).