Unmet peer dependency with package update

[hoppities]

Hello!

We noticed a fail in our build process when the new version of follow-redirects came out yesterday.

+-- axios@0.17.1
| +-- UNMET PEER DEPENDENCY debug@^3.0.0 || ^4.0.0
| +-- follow-redirects@1.12.0

[RubenVerborgh]

Peer dependencies should only result in warnings:

$ npm install follow-redirects@1.12.0
npm WARN saveError ENOENT: no such file or directory, open '/private/tmp/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/private/tmp/package.json'
npm WARN follow-redirects@1.12.0 requires a peer of debug@^3.0.0 || ^4.0.0 but none is installed. You must install peer dependencies yourself.
npm WARN tmp No description
npm WARN tmp No repository field.
npm WARN tmp No README data
npm WARN tmp No license field.

+ follow-redirects@1.12.0
updated 1 package and audited 1 package in 0.445s
found 0 vulnerabilities

I suggest to configure your build system such that it treats these accordingly, instead of as failures.

Alternatively, you can include debug@3.x or debug#4.x as a dependency of your project, but follow-redirects will work fine without it. See #116, #123.

[hoppities]

Okay, yeah, I'm seeing that. This might be a CI/CD tool configuration issue that caused this. Thanks!

[mikeharder]

@RubenVerborgh: I believe adding a peer dependency is considered a breaking change (per semver/semver#502), so this should be released in a new major version of follow-redirects (not a new patch version).

Would you consider unpublishing or deprecating 1.12.0, and instead releasing this change in 2.0.0?

[RubenVerborgh]

Thanks @mikeharder for detailing your concern.

The short version: the dependency is completely optional, in that its absence will not affect functionality. It will just work as it should. So since there is no impact, no major version change is needed.

The longer story: this package is under many constraints, including usage on old Node versions (which is the whole reason for this peer dependency). What I want to do is have debug@4.x as an (optional) dependency, but I can't because then it would break older versions. Given that this package is currently unfunded, I don't have the resources to maintain multiple versions simultaneously. So the dependency route is not an option.

Releasing a new major version would cause this package (which is widely depended on) to not be updated in all of those places that still use v1.x, or I'd again be stuck with maintaining multiple versions.

Given that nothing well-configured breaks, I think peerDependencies is an acceptable solution, especially given the optional nature of a debugging package.

[mikeharder]

So since there is no impact, no major version change is needed.

In my opinion, causing a build warning is sufficient impact to justify a new major version. Projects may have enabled "warnings as errors" or otherwise have a policy that builds should have no warnings.

Releasing a new major version would cause this package (which is widely depended on) to not be updated in all of those places that still use v1.x, or I'd again be stuck with maintaining multiple versions.

I don't see why you would need to maintain multiple versions. Consumers could choose to stay on ^1.0.0 (where the latest version ever released will be 1.11.0) or upgrade to ^2.0.0 and deal with the peer dependency.

[RubenVerborgh]

Projects may have enabled "warnings as errors" or otherwise have a policy that builds should have no warnings.

Yes, I just learned about that indeed.

Consumers could choose to stay on ^1.0.0 (where the latest version ever released will be 1.11.0) or upgrade to ^2.0.0 and deal with the peer dependency.

Yeah, I'd probably still get bug reports in on the 1.x branch, with people who are stuck there because it's a transitive dependency.

Not an easy situation and I do see the inconvenience it's causing in your builds. I will give it a couple of days to see what other reactions come in; I have had to roll back a change to debug in the past when it became clear that too many things were affected.

I could also just drop debug from peer dependencies actually. If it's there, it will be picked up; if not, it won't be. Maybe that's a good solution.

[RubenVerborgh]

You know what, I'll just remove the peerdep. Will solve our headaches.

[ylemkimon]

@RubenVerborgh npm (npm/cli#224) and Yarn supports peerDependenciesMeta field in the pakcage.json, which allows to mark a peer dependency as optional.