Right? I'm a web developer and work a lot with PHP.
PHP's de facto package manager is Composer and it's very simple and clear in how it works:
Your composer.json states your dependencies and their version constraints.
Your composer.lock (also a json file) states the actual versions that should be installed, based off your composer.json.
"composer install" installs the exact versions from your composer.lock file, "composer update [package]" updates the lock file based on your constraints.
With npm this doesn't seem to be as straight-forward, sometimes I run "npm install" and the package-lock.json ends up changing, I definitely don't consider npm to be safe.
This is why you should use yarn v2 or v3. Dependencies clusterfck are not a thing with yarn. We went from having a lot of weird bugs like that every month to having zero, for 2 years thanks to yarn. The counterpart is that yarn sometimes needs your input, when package maintainers don’t declare their does or peerDeps correctly.
Is that due to yarn v2 including a zipped version of all the dependencies that you can check into the repo?
Because that is what I plan to do. Such a pain when some random dependency 50 packages deep is broken or even pulled from npm and so we can't even finish a deployment build until fixed. Especially for older projects.
It’s is first and foremost due to the “mathematically correct” (or at least “more correct”) resolution algorithms used in yarn. And it is further improved by the local caching of packages indeed. Note that you can even be in “zero install” mode with yarn, where you checkout in git this dependency cache, so you never have to “yarn install”, got checkout is enough to get everything. If npmjs.com falls down you wouldn’t be in any trouble.
Composer is not that much better though. It has (had?) the brain dead convention, that you may only refer to branches by prepending "dev" or "dev-", which itself can be a branch name and an organizational convention and thus the convention prescribed by composer gets in the way unnecessarily with what an organization may already have as convention.
So I am not sure it is better than npm, however, at least one does not have that split in package managers, which will additionally create friction in or between teams and projects.
> I run "npm install" and the package-lock.json ends up changing
This is intended behaviour, but seems totally counterintuitive to me. I’m with you, I’m used to Composer and NPM just seems inscrutable at times.
For reference, the approximate equivalent to `composer install` is `npm ci`. This will install the exact versions from package.lock without changing it, however it will also blow away your node_modules directory and install from scratch each time.
PHP's de facto package manager is Composer and it's very simple and clear in how it works:
Your composer.json states your dependencies and their version constraints.
Your composer.lock (also a json file) states the actual versions that should be installed, based off your composer.json.
"composer install" installs the exact versions from your composer.lock file, "composer update [package]" updates the lock file based on your constraints.
With npm this doesn't seem to be as straight-forward, sometimes I run "npm install" and the package-lock.json ends up changing, I definitely don't consider npm to be safe.