A static archive of Markus Tacker's tweets. Follow me on Mastodon: @[email protected].
I have a frontend project with 30-something dependencies just for building the
project (rollup, babel, ...) and these receive updates every day. This is not an
issues when working with the latest code, but when fixing bugs for older
releases of the project, it gets nasty.
Since your package.json might include dependencies which are not fixed, but
point to some version of a package through the use of "^1.0.3", you will end
up with an arbitrary configuration of you build chain, when doing a git checkout
old-release; npm i
This might break, and for me it did yesterday.
It took me roughly two hours to figure out what is wrong, and since I am not an
expert for this specific build chain. In general it's hard to retrace bugfixes
and breaking changes anyway.
Now npm ci could have saved me:
If you maintain an up-to-date package-lock.json (by using npm 5), npm ci will
install the exact dependencies from the lockfile where an npm i will install the
latest release that matches your version specification in package.json. This
means you can retrieve exact configurations.
So, npm ci gives you the ability to keep the forward looking way to manage
dependencies in JavaScript we all love but gives you the safety that you can
always go back in time to a configuration which once worked.