4 ms·
This is what happens when you don't pin your dependencies, right?
by rigaspapas 8y ago
This is what happens when you don't pin your dependencies, right?
- ameliaquining 8y agoIt's indeed a good reason for apps to pin their dependencies; those that did so presumably didn't have their builds broken by this issue. I don't feel that pinning dependencies necessarily makes a whole lot of sense for libraries, since it creates inflexibility and dependency duplication for app developers. But opinions vary.
- jessaustin 8y agoWouldn't we consider the way that most people use webpack to be as an app, not as a library?
- ameliaquining 8y agoNo, because you declare it as a dependency.
- jessaustin 8y agoIs this a novel definition of "library"? To me, library code is called by my code while my code is running. So, most libraries are dependencies, but lots of dependencies are not libraries. Test, code coverage, or documentation tools might be dependencies, or as npm would say instead devDependencies, but they are not libraries. Similarly, webpack is what we might call a build tool, which is also not a library.
- ameliaquining 8y agoI think it's just a semantic distinction, not a substantive one. The relevant thing is indeed that Webpack is generally used as part of another build process.
- jessaustin 8y agoOK let's go with your definition. You're saying that "endpoints" may pin their dependencies, but any package that is depended upon by some other package should not in turn pin its own dependencies. ITT, I don't see support for this proposition. 'rigaspapas observed that the problems described in TFA could have been avoided through pinning. Presumably you're thinking of other problems that could be caused by pinning, but why would you think those problems are any worse than causing the program to completely fail to accomplish anything?
- ameliaquining 8y agoNot necessarily worse, but more common. Diamond dependencies happen a lot, especially in npm.
- jessaustin 8y agoDiamonds are more common because node unlike many environments is absolutely tolerant of them. Maybe this "wastes" some disk space, but otherwise this is not a problem. It is orthogonal to actual problems like bugs in particular package versions.