Unable to install on node 16

[Dossar]

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.

[israelsgalaxy]

Came here to report this same issue

[johnnyreilly]

Looks like npm is the issue here, not node 16. Looking at the error message it suggests babel-loader may be the cause?

I'm unclear what a fix here would look like. Happy to take a PR if someone has an idea. For now it looks like you can use the --force flag to get going.

[unional]

It's the strict-peer deps issue. npm@8, yarn@3, pnpm are moving to that model. So make need to update the deps soon.

[johnnyreilly]

Oh really? Might pivot ts-loader back to npm from yarn then

[unional]

Strict-peer deps is for the better in general. The NPM peer dependency resolution was broken to begin with, so the tools finally trying to right the boat.

[johnnyreilly]

https://stackoverflow.com/questions/64573177/unable-to-resolve-dependency-tree-error-when-installing-npm-packages/64615583#64615583

Try this command-

npm install --save --legacy-peer-deps

[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).

[unional]

Just for the record, no, we are not.

Good to know. I thought it was doing similar thing as pnpm. thx for the clarification. 🌷

[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 🙂