Unpin dependencies. #719
Unpin dependencies. #719
Conversation
Pinned dependencies give a false sense of security. Only shrinkwrapping can protect against semver abuse and other updating perils. In lieu of that, caret ranges have the best risk/reward story.
|
I would say that Intern takes a reasonably consistent approach to its use of pinned dependencies; originally all dependencies were pinned, and currently all non-Intern dependencies are pinned. (Dig Dug and Leadfoot were unpinned so that bug fixes could come through without requiring a new Intern release.) I agree that only pinning top-level dependencies isn't particularly thorough, but while unpinning them may provide quicker access to new features, it magnifies the likelihood that something will break (as the CI test run shows). At the moment I lean towards shrinkwrap, or at most using '~'. |
👍 |
Fair. It is consistent in that sense. I would ask, though, if you trust updates from yourself, why not new features?
I haven't looked deep into the root cause of the Travis failure, but it failed only on Node 0.12 with a simple In regards to stability, note that many of your fellow testing frameworks such as AVA and Mocha use caret ranges and don't shrinkwrap. While I wouldn't use that as a reason alone to do this, I think it's meaningful to demonstrate that other stability-minded folks are getting along just fine with this. |
I'm not so concerned with why something is broken so much as the fact that it's broken. With pinned dependencies, we (theoretically) know that users will end up with a product that has been tested. When we use tilde ranges, the odds go up that a user will encounter something broken, but those odds should still be reasonably low since tilde implies small changes. With caret ranges the odds of encountering breaks go up again, because much larger changes are allowed. Noticing that Intern is broken isn't too bad -- we can just run a daily or weekly CI cron job to check that current installs work. However, dealing with the problem becomes much more of an issue, because now all new installs of Intern are broken until we do something about it (either pinning to a known good version of a dependency or writing around the issue).
My main concern isn't that the projects aren't tested, it's that they aren't necessarily tested in the same environments that Intern is. The CI failure is a good example of this. At least one of the dependencies wasn't tested in, or may explicitly no longer support, Node 0.12, which Intern still technically does.
I'm not completely against using looser dependency versions, but I'm still not sure that the benefits necessarily outweigh the accompanying maintenance headaches. |
|
Closing for lack of interest combined with merge conflicts and CI failure. 👻 |
Intern has previously had a very inconsistent use of pinned and unpinned dependencies. This PR aims to normalize that and improve the user experience when upstream features are released that do not require code changes to Intern (e.g. new tunnels or env vars added to DigDug).
The basic premise here is that whatever gain is had from pinning the immediate dependencies is cancelled out by virtue of the nested dependencies using ranges themselves (extremely common, in part due to
npmdefaults).So in effect, prior to this PR, Intern still experiences the dangers of version ranges, but without the benefits. I think Intern should either shrinkwrap its dependencies or use this PR.
I left
dojoalone since it is pinned to a pre-release version. Using^2.0.0-alpha.7is valid, but since it matches both pre-releases and releases, if a breaking change happens prior to a proper release, that would be problematic, which seems within the realm of possibility (and is allowed by the spec).