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........)
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.
> 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.
