Personally, I've never got into shrinkwrap. In my opinion, it's another barrier to contribution and another place for mistakes to be made.
I prefer on the old-school "shrinkwrap" approach, which is explicitly specifying each dependency version: https://github.com/phonegap/phonegap-cli/blob/master/package.json#L29-L40 Discrete and explicit commits mark where and when dependencies are upgraded: https://github.com/phonegap/phonegap-cli/commit/e6d68e47a3a5cf4e9e6308467a6ae7716f6c5f9d It's clean. It's simple. It's an `npm install` away. With that said, shrinkwrap can be useful when our projects are using a fork of a dependency that hasn't accepted our patch. Do we have that use case in Cordova? In general, I lean the approach that is simpler, less error prone, and encourages new contributors. Thanks for starting this discussion Marcel! Michael On Thu, Sep 18, 2014 at 11:55 AM, Mark Koudritsky <kam...@google.com> wrote: > > > > > > Mark, > > I want to understand better your statement "resulted in a great deal of > > confusion for contributors". Can you give more details about that. > > > One simple case I had myself was when debugging a suspected problem with > one of dependencies and wasting several hours to only discover that the > dependency version setting in package.json was ignored due to presence of > npm-shrinkwrap. It's stupid simple, but since shrinkwrap is not a very > common tool, people are not aware of it, or just forget that it's there. > While for us it's the center of this discussion, the average cordova > contributor is likely to not even remember what the decision was about > which repos should contain it when etc. >