3 ms·
The only way to prevent this is to pin the actual commit. Because the meaning of the semantic version numbers is up to the package maintainers in most packaging
by bayesian_horse 5y ago
The only way to prevent this is to pin the actual commit. Because the meaning of the semantic version numbers is up to the package maintainers in most packaging systems. And even then you need a way to source exactly that version without relying on the original author's cooperation.
Pinning all dependencies to this extent is extremely inconvenient. More inconvenient, arguably, than to deal with this shit once in a while...
- ownagefool 5y agoThat's what .lock files do though.
- bayesian_horse 5y agoNot sure if that is even enough, at least in NPM the .lock files work on semantic versions, not commits. I'm not sure if NPM enforces you to change the semantic version with each commit. And even if all of that works, you still run head first into the issue once you inevitably upgrade the dependencies.
- epmatsw 5y agoYarn at least includes a hash of the tarball in the lockfile, so even if npm’s immutability fails somehow you’ll at least know.
- xg15 5y agoThen the package manager should be changed to make it more convenient.
- bayesian_horse 5y agoThere is no way around the issue because "dependency hell" is indeed a thing. Dependencies change. Dependencies of dependencies change. You can't not update any of your dependencies for too long or there will be other problems. Something is gotta give.
- reasonabl_human 5y agoThis is why I’ve warmed up to Nix, pinnacle of dependency management IMO