Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
@xenira
npm@5.3.0 vs yarn@0.27.5
# uncached run:
npm: added 1737 packages in 103.054s
yarn: Done in 55.81s.
# cached run:
npm: up to date in 9.151s
yarn: Done in 5.13s.
I still rather use yarn than npm. -
@k0pernikus can understand that, just wanted to throw in that npm got a lot better :)
Found something true as 1 == 1
Code I wrote: 15kb
NPM Modules: 198Mb
This is where US's bandwith is going
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!?
undefined
lockfile
npm
package.json
yarn.lock
yarn
sensible defaults