Lock in Dependencies & Sub Dependencies

[gaurav21r]

Yesterday we were working on our project when a node module A stopped working the moment our team ran npm install X (X wasn't A).

I checked A individually pulling it out of our app's source code. It was indeed not working. Infact A wasn't updated for the last 2 weeks! So what happened?

A had a sub dependency B which was updates in the last 2 days which made A stop working! And therefore made our project stop working!

We have to lock in dependencies by:

1. Removing the ^ in package.json.
2. Using --save-exact

We have to lock in sub dependencies by:

1. Using npm shrinkwrap . https://docs.npmjs.com/cli/shrinkwrap

We also have to advice our Users to choose between locking in Deps or Free Updates. Locking In deps (as the article on shrinkwrap suggests) has a few steps. I will be making a note of it here soon.

cc @riteshe63 @dixhap @kundan873 @prakash1517 @rcorp/engineers @rcorp/owners @nitinmadeshia @neerajsachan

[gaurav21r]

Here we have a philosophical discussion as well. Is locking dependencies actually good?

• YES! This bring stability to my project. I can recreate the environment in all my dev machines.
• NO! This is the JS / npm ecosystem. I need to move fast and break things. My project has quickly become outdated because of outdated dependencies.

Based on my research, apps (user facing projects) tend to favour stability and will want to lock in deps while utilities / tools (dev facing projects) would love to be on the bleeding edge of their deps (generally)!

I'll bring in some references and we can maybe leave this up for more discussion.