fallback for broken modules #4337

rlidwka opened this Issue Dec 17, 2013 · 4 comments


None yet
4 participants

rlidwka commented Dec 17, 2013

Feature request:

Sometimes a certain version of a package is not available or can't be installed.

For example, if couchdb eats tarball for a dinner (happens quite frequently), or someone publishes broken package (no loss of generality in assuming npm@1.3.19).

We can try and install earlier version of the same package in this case.


othiym23 commented Dec 17, 2013

I agree that npm's recent scaling problems are infuriating and painful, but I think this is the wrong kind of resiliency. I can see a justification for falling back to an older version for npm install whatever, but the general case introduces nondeterminism into a process that needs to be consistent and repeatable, especially in the case of something like the recent cordova / PhoneGap problem where there was a SHA verification failure. This seems like a short-term fix for a long-term problem.


luk- commented Dec 17, 2013

We can't write features for the client that assume the back end is going to be broken.


rlidwka commented Dec 17, 2013

but the general case introduces nondeterminism into a process that needs to be consistent and repeatable

It is neither right now anyway, since people can unpublish and publish back certain package with an exactly same version, and I believe I observed bson@0.2.3 doing exactly this.


othiym23 commented Jun 3, 2016

Surprisingly enough, my thinking on this hasn't changed too much in the last two and a half years (my comment up-thread was actually long before I even knew that working at npm was a possibility): I don't think it's a good idea for the CLI to mechanically fall back to previous versions when the current install fails, even in an operational environment as chaotic as the 2013-era registry. If the registry loses a tarball, that's an operational error that should (and these days is) promptly be addressed by the registry's operational team; if a broken package gets published, that's what deprecation and unpublishing are for.

There is a case to be made that it should be easier to pin a dependency below the top-level in a project more simply than by creating a shrinkwrap and editing it by hand, but that's a different use case than the one described in the original post.

As such, I'm going to close this issue. Thanks for your time!

@othiym23 othiym23 closed this Jun 3, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment