4 ms·

"static linking", as in compiling libraries into the final executable, wouldn't help here. If anything it makes the problem worse since it's harder to find all

by 0x0 11y ago

"static linking", as in compiling libraries into the final executable, wouldn't help here. If anything it makes the problem worse since it's harder to find all instances of a library when applying updates. But maybe you mean "bundling the dependencies", or at least refering to exact versions by cryptographically secure hashes, including all transitive dependencies. I've seen lots of "package.json" files refering to ">=2.2" which is horrible from a reproducibility standpoint. I like the way composer writes out "composer.lock" files which specify exact versions. Thus, even if you don't want to check in the "vendor/" subdirectory into your VCS, you should at least more or less be able to reproduce your dependencies exactly. Of course, checking in your "vendor/" dir is even better since your build no longer depends on an internet connection and an available remote server. Or maybe all those scripting languages and their associated package managers (npm, gem, composer, etc) should take a note from the dpkg/rpm/C-style "lib*.so" world. Settle for stable APIs and stick with a release for the lifetime of an OS edition.

tdumitrescu 11y ago
Re: your issues with package.json, npm has long had the capability to produce 'shrinkwrap' files analogous to composer.lock/Gemfile.lock etc with the 'npm shrinkwrap' command. That doesn't excuse the use of '>=' version specifications (I frankly don't see any use case for it), but all these package managers are explicitly designed to allow flexibility in specifying dependency versions - in theory, if your dependencies follow semver, you should always be safe with a patch-level version bump. (Of course, in actual practice........)
- noir_lord 11y ago
  My favorite amongst the package managers I use is pip's freeze command which dumps the installed local venv packages straight out with fixed versions. pip freeze > requirements.txt (to output) and pip install -r requirements to install.
- plorkyeran 11y ago
  The use-case for '>=' etc. is when writing an open-source library which depends on other libraries. Even with npm's ability to have multiple versions of each library at once, you don't want to have to ship a new version every time one of your dependencies does. Even if you don't mind the hassle, you'd still making it harder for your users to promptly install security fixes. Using it for an open-source application can make sense for similar reasons, but for an internal application where cutting a release and deploying upstream security fixes are the same operation it's pretty pointless.
  - copsarebastards 11y ago
    > Even with npm's ability to have multiple versions of each library at once, you don't want to have to ship a new version every time one of your dependencies does. Nothing about using == forces you to ship a new version every time one of your dependencies does. When your dependencies ship a version, this changes nothing for you if you're using ==. In fact, >= is much more likely to force you to ship a new version when one of your dependencies does, because a breaking change in your dependencies can break your code. And when a breaking change breaks your code, it does so without warning. >= is a cause of your problem, not a solution. > Even if you don't mind the hassle, you'd still making it harder for your users to promptly install security fixes. If you're worried about security, then you shouldn't be shipping arbitrary dependency updates to your users, you should be evaluating the security of each release before pushing them out. And honestly, if you're writing security-critical code, you shouldn't be using a language that dumps everything into a global namespace. "JavaScript security" is an oxymoron.
noir_lord 11y ago
I never use anything but the exact versions in my .lock files (unless there is a really compelling reason not to). If I want to upgrade from 2.1.3 to 2.1.4 then I'll change that dependency and run the update. The reason I do this if I have packages A, B and C all set to >=2.2 and A,B upgrade and something breaks, How do I know it if twas A or B. Now throw in that packages get updated all the time and those packages have sub dependencies and it quickly can get out of hand.
- viraptor 11y ago
  This may be reasonable or not, depending on what are you developing. But there's no one solution for everything. Is it an app just for you? Exact versions are great. Is it an app for someone else? You should probably allow security fix updates, so at least x.y.*. Is it a library? Anything close to a specific version is a terrible idea. Just define a minimal supported version and maybe an upper limit on (x+1).0.0.

by 0x0 11y ago

tdumitrescu 11y ago

Re: your issues with package.json, npm has long had the capability to produce 'shrinkwrap' files analogous to composer.lock/Gemfile.lock etc with the 'npm shrinkwrap' command. That doesn't excuse the use of '>=' version specifications (I frankly don't see any use case for it), but all these package managers are explicitly designed to allow flexibility in specifying dependency versions - in theory, if your dependencies follow semver, you should always be safe with a patch-level version bump. (Of course, in actual practice........)

noir_lord 11y ago
My favorite amongst the package managers I use is pip's freeze command which dumps the installed local venv packages straight out with fixed versions. pip freeze > requirements.txt (to output) and pip install -r requirements to install.
plorkyeran 11y ago
The use-case for '>=' etc. is when writing an open-source library which depends on other libraries. Even with npm's ability to have multiple versions of each library at once, you don't want to have to ship a new version every time one of your dependencies does. Even if you don't mind the hassle, you'd still making it harder for your users to promptly install security fixes. Using it for an open-source application can make sense for similar reasons, but for an internal application where cutting a release and deploying upstream security fixes are the same operation it's pretty pointless.
- copsarebastards 11y ago
  > Even with npm's ability to have multiple versions of each library at once, you don't want to have to ship a new version every time one of your dependencies does. Nothing about using == forces you to ship a new version every time one of your dependencies does. When your dependencies ship a version, this changes nothing for you if you're using ==. In fact, >= is much more likely to force you to ship a new version when one of your dependencies does, because a breaking change in your dependencies can break your code. And when a breaking change breaks your code, it does so without warning. >= is a cause of your problem, not a solution. > Even if you don't mind the hassle, you'd still making it harder for your users to promptly install security fixes. If you're worried about security, then you shouldn't be shipping arbitrary dependency updates to your users, you should be evaluating the security of each release before pushing them out. And honestly, if you're writing security-critical code, you shouldn't be using a language that dumps everything into a global namespace. "JavaScript security" is an oxymoron.

noir_lord 11y ago

I never use anything but the exact versions in my .lock files (unless there is a really compelling reason not to). If I want to upgrade from 2.1.3 to 2.1.4 then I'll change that dependency and run the update. The reason I do this if I have packages A, B and C all set to >=2.2 and A,B upgrade and something breaks, How do I know it if twas A or B. Now throw in that packages get updated all the time and those packages have sub dependencies and it quickly can get out of hand.

viraptor 11y ago
This may be reasonable or not, depending on what are you developing. But there's no one solution for everything. Is it an app just for you? Exact versions are great. Is it an app for someone else? You should probably allow security fix updates, so at least x.y.*. Is it a library? Anything close to a specific version is a terrible idea. Just define a minimal supported version and maybe an upper limit on (x+1).0.0.