cordova-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michal Mocny <>
Subject Re: [DISCUSS] shrinkwrap
Date Mon, 29 Sep 2014 21:27:45 GMT
>From the latest npm podcast thing Carlos sent out, seems the conclusion is
that the npm overlords advise we do use shrinkwrap.

Most of the issues are currently *not* surrounding how shrinkwrap is
implemented, but rather just with the tools being unclear when decisions
are made because of its existence.  Patches are likely to land in npm to
make it more clear, so you don't accidentally shoot yourself in the foot as
we did, but due diligence and following the release instructions probably
also gets us there today.

For those reasons, I've now changed my mind and now think we should leave
it in.


On Mon, Sep 29, 2014 at 4:45 PM, Marcel Kinard <> wrote:

> I didn't see a consensus on this topic yet, and a tools release is about
> to get rolling by Steve.
> My original driver for this discussion is that if we are going to do
> shrinkwrap, that we do it all the way instead of slapping it on at the end.
> Doing it does add more complexity. But it also removes variability, that's
> the part I like. If the majority of folks want to skip the shrinkwrap, I
> would be OK with that as long as we specifically pin all our dependencies (
> "foobar": "1.2.3" ) in our package.json files (no ".x", no tilde, caret,
> greater-than, etc). That would handle the 1st-level dependencies, but not
> subdependencies since we don't have control of their package.json - it's
> partway to the destination at a lower cost. This also assumes that partway
> to the destination is good enough.
> I did add a step to the tools release that the pinned versions get updated
> at the beginning of a release:
> Comments?
> On Sep 22, 2014, at 10:01 AM, Andrew Grieve <> wrote:
> > I like having it in. For CCA, we actually did get bit in a release where
> we
> > didn't have a shrinkwrap and a descendant dependency changed and broke
> > things on us.
> >
> > It's also really nice that when we sign and vote on a release, that doing
> > an "npm install" on it down the line will recreate the exact thing we
> > tested & signed.
> >
> > I think the trouble came along here just from incomplete release step
> > instructions. I think that this (lack of clear steps / process) is the
> real
> > problem.

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