cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carlos Santana <csantan...@gmail.com>
Subject Re: [DISCUSS] shrinkwrap
Date Fri, 19 Sep 2014 01:04:36 GMT
@Michael I agree if we think it's going to affect contribution, let's
implemented in a way that is not affect them at all. and find ways to keep
it uptodate and part of the released process.

On Thu, Sep 18, 2014 at 4:39 PM, Michael Brooks <michael@michaelbrooks.ca>
wrote:

> >
> > 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 <csantana23@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) <
> > panarasi@microsoft.com> wrote:
> >
> > > Also a quick question. Will we be withholding the 3.6.* release till we
> > > resolve this discussion?
> > >
> > > -----Original Message-----
> > > From: mikeywbrooks@gmail.com [mailto:mikeywbrooks@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 <kamrik@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
> > <csantana23@gmail.com>
> >
>



-- 
Carlos Santana
<csantana23@gmail.com>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message