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. On Fri, Sep 19, 2014 at 3:18 PM, Carlos Santana <csantan...@gmail.com> wrote: > kidding aside if the community feels strongly to take it out from both npm > and git, I would respect the decision and shut up ! > I live and die by the community :-) > > On Fri, Sep 19, 2014 at 3:11 PM, Carlos Santana <csantan...@gmail.com> > wrote: > > > It's working fine today being present in the npm package, I don't think > we > > should remove it just because of a "feeling" > > > > > > > > On Fri, Sep 19, 2014 at 2:51 PM, Brian LeRoux <b...@brian.io> wrote: > > > >> ha, legal! thats why but thats not a technical reason. =) > >> > >> we could argue all day about subjective things like architecture but > >> generally speaking in the node community the feeling is that shrinkwrap > is > >> harmful … we do not have a technical issue here, nor have we, but we do > >> have deployment complexity and issues with shrinkwrap so I stand by the > >> lazy consensus here that this is YAGNI > >> > >> > >> On Fri, Sep 19, 2014 at 11:41 AM, Carlos Santana <csantan...@gmail.com> > >> wrote: > >> > >> > + 1 leave it in npm package > >> > + 1 take it out from git > >> > > >> > Technical reasons: > >> > 1. better architecture to have all end user use the same version of > all > >> the > >> > code. > >> > 2. when we test here in ibm and install cordova from npm we know that > >> all > >> > testers are testing the same code, > >> > Legal related reason: > >> > 1. We need to create a package with cordova and all other 100 npm node > >> > module dependencies it's easier to identify what npm package versions > we > >> > need to legally bless and re-distribute. > >> > > >> > > >> > On Fri, Sep 19, 2014 at 2:32 PM, Brian LeRoux <b...@brian.io> wrote: > >> > > >> > > So I think its neat we had a vote but was there a technical reason > for > >> > it? > >> > > Nope. Lets kill it. > >> > > > >> > > > >> > > On Fri, Sep 19, 2014 at 11:23 AM, Carlos Santana < > >> csantan...@gmail.com> > >> > > wrote: > >> > > > >> > > > @Brian shrinkwrap was implemented in the release process because > it > >> was > >> > > > discuss in the mailing list and agreed, no -1 votes > >> > > > http://markmail.org/thread/j6bv5bk5ndlokobj > >> > > > > >> > > > can someone show me a jira issue or contributor having problems > with > >> > > having > >> > > > npm-shrinkwrap.json in the npm package only? > >> > > > > >> > > > > >> > > > On Fri, Sep 19, 2014 at 1:30 PM, Brian LeRoux <b...@brian.io> wrote: > >> > > > > >> > > > > I'm w/ Mike on this. No idea why we started using shrinkwrap, > its > >> > > always > >> > > > > had a flaky rep, and if we don't remember why then I'm guessing > we > >> > > might > >> > > > > have decided to use it for reasons that may have been more > >> defensive > >> > > than > >> > > > > actually solving a problem we had. Lets turf it. If bugs get > >> reported > >> > > > then > >> > > > > we can bring it back. > >> > > > > > >> > > > > On Fri, Sep 19, 2014 at 9:37 AM, Marcel Kinard < > >> cmarc...@gmail.com> > >> > > > wrote: > >> > > > > > >> > > > > > > >> > > > > > On Sep 18, 2014, at 1:32 PM, Parashuram Narasimhan (MS OPEN > >> TECH) < > >> > > > > > panar...@microsoft.com> wrote: > >> > > > > > > >> > > > > > > If we do have shrinkwrap in git at all times, who would be > >> > > > responsible > >> > > > > > for updating not only the versions of our dependencies, but > also > >> > the > >> > > > > > dependencies of these dependencies? > >> > > > > > > >> > > > > > One thought on this is that the release manager could do it at > >> the > >> > > > > > beginning of a new release on master, separate from the > >> > > tagged/branched > >> > > > > > release that is being packaged for release. Similar to how we > >> add a > >> > > > > "-dev" > >> > > > > > suffix, that's when there could be a systemic refresh. And of > >> > course, > >> > > > if > >> > > > > a > >> > > > > > developer finds a technical driver to refresh the dependents > and > >> > > > > shrinkwrap > >> > > > > > in the middle of a dev cycle, it would happen there too. > >> > > > > > > >> > > > > > > Why should cordova-lib and cordova-plugman not have > >> shrinkwraps? > >> > > Not > >> > > > > all > >> > > > > > tools use cordova-cli as a way to build cordova apps. There > were > >> > also > >> > > > > > discussions about using cordova-lib being the public API to > >> build > >> > > apps. > >> > > > > If > >> > > > > > that is the case, judging by our shrinkwrap philosophy, we > need > >> > that > >> > > > file > >> > > > > > on all repos that we say are public API. > >> > > > > > > >> > > > > > My thinking is that since a shrinkwrap is fully recursive, > only > >> the > >> > > > > > top-level package needs to have the shrinkwrap. If there is a > >> > > separate > >> > > > > > third-party app that uses cordova-lib, they can choose whether > >> or > >> > not > >> > > > to > >> > > > > > have a shrinkwrap, and it wouldn't be partially forced on them > >> by > >> > its > >> > > > > > presence inside cordova-lib. Well, and it's also a pain for > us > >> to > >> > > > > generate > >> > > > > > shrinkwraps inside our own dependencies. > >> > > > > > >> > > > > >> > > > > >> > > > > >> > > > -- > >> > > > Carlos Santana > >> > > > <csantan...@gmail.com> > >> > > > > >> > > > >> > > >> > > >> > > >> > -- > >> > Carlos Santana > >> > <csantan...@gmail.com> > >> > > >> > > > > > > > > -- > > Carlos Santana > > <csantan...@gmail.com> > > > > > > -- > Carlos Santana > <csantan...@gmail.com> >
