I will die younger because of node packages

It's like quantum mechanics, so undeterministic, even with yarn.lock, I had this meeting to demo software and I was ready for 2 min past the meeting time, having worked nearly all night to save monorepo yarn workspaces issues where some module has peer dependency it shouldn't have and some other module installed a newer version of a package which broke another module with another version of the same package, one module checks if it's got an instanceof another package, but it returns false because it's another version of the same package that created it so X !== X.

I nearly had a nervous breakdown and my node modules won't fix when I remove all node_modules in the yarn+lerna monorepo and reinstall from scratch... it's like seeing ghosts with these errors all works for months and then a butterfly splashes its wings near 1 node module and the entire app fails apart.

:'''(

So I have replaced npm with yarn due to performance boost and the lockfile.

Never will there be problems with unexpected versions of dependencies!

Wait.

Why is my build writing a yarn.lock?

It turns out, if you want yarn to exit with an error code if it's out of sync with the package.json, you have to run it with:

$ yarn install --frozen-lockfile

Only then it will produce an error.

The default for it is to notice, oh, there is some new dependencies, let resolve this to the most current version I can fetch, and use that one, and write a new lockfile. Meaning you will get unknown futures of a depdency. O_o

That's totally going besides the purpose of having a lockfile in the first place. Why would anyone want this?

Action I do expect to touch the lockfile:

add / remove / upgrade

Action I do NOT expect to touch the lockfile:

install

Install should just install whatever is in there, and if it realizes it is out of sync, die with an error.

But that would make sense!

Who needs sensible defaults anyway!?