>
> But here is the trick even if we put the specific version of the dependency
> in our package.json that doesn't guarantee that down the dependency chain
> different versions of node modules get install based on the time of the
> install.
@Carlos very true and I didn't cover that topic. Personally, I've never
been hit by this issue (to my knowledge). If it's a major concern for
Cordova, then shrinkwrap is the option to go with. Although, let's just
ensure it's a problem that we've felt before complicating the contribution
process.
Michael
On Thu, Sep 18, 2014 at 1:28 PM, Carlos Santana <csantan...@gmail.com>
wrote:
> Like I said in my initial proposal to use shrinkwrap the minimum
> requirement is that is included when publishing to npm, is the only way
> that we can trace problems and what are the bits that end user is using in
> case of a problem.
> I don't want for committers to waste time troubleshooting something that is
> not at fault of cordova code but in a node module provided by 3rd party
> that we depend down the chain.
>
> Michael,
> I agree with having specific versions for our, and I think we should
> move forward and be explicit about the version of dependencies in our
> cordova's pacakge.json, and update them as we see it fit.
>
> But here is the trick even if we put the specific version of the dependency
> in our package.json that doesn't guarantee that down the dependency chain
> different versions of node modules get install based on the time of the
> install.
>
> For example in cordova-lib we have an explicit dependency for
> request@2.22.0
>
>
> But if you take a look at the pacakge.json of request@2.22.0 they don't
> use
> explicit dependencies, so we don't have control to lock down the versions
> use by request one end user can be using qs@0.6.0 and a later user can
> install be using qs@0.6.1 . this is just a fake example but you see what I
> mean when I say we can lock our level of dependencies only.
>
> "dependencies": { "qs": "~0.6.0", "json-stringify-safe": "~4.0.0",
> "forever-agent": "~0.5.0", "tunnel-agent": "~0.3.0", "http-signature":
> "~0.10.0", "hawk": "~0.13.0", "aws-sign": "~0.3.0", "oauth-sign": "~0.3.0",
> "cookie-jar": "~0.3.0", "node-uuid": "~1.4.0", "mime": "~1.2.9",
> "form-data"
> : "0.0.8" },
>
>
>
>
>
>
> On Thu, Sep 18, 2014 at 3:50 PM, Parashuram Narasimhan (MS OPEN TECH) <
> panar...@microsoft.com> wrote:
>
> > Also a quick question. Will we be withholding the 3.6.* release till we
> > resolve this discussion?
> >
> > -----Original Message-----
> > From: mikeywbro...@gmail.com [mailto:mikeywbro...@gmail.com] On Behalf
> Of
> > Michael Brooks
> > Sent: Thursday, September 18, 2014 12:18 PM
> > To: dev@cordova.apache.org
> > Subject: Re: [DISCUSS] shrinkwrap
> >
> > 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.
> > >
> >
>
>
>
> --
> Carlos Santana
> <csantan...@gmail.com>
>
