rcorp / standard-project-structure

A mission to improve developer productivity. Automate Everything ™ !
Apache License 2.0
5 stars 3 forks source link

Lock in Dependencies & Sub Dependencies #31

Open gaurav21r opened 7 years ago

gaurav21r commented 7 years ago

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 commented 7 years ago

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

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.