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>
