Okay, I think I'm convinced then. It's just too tricky to get right at the moment. Let's drop shrinkwrap and just do pinning for now. Once it's less of a hassle to use it, we can try it out again.
On Wed, Oct 1, 2014 at 8:09 PM, Carlos Santana <[email protected]> wrote: > +1 on private/staging npm registry for playground and voting. > +1 pinning, it doesn't solve everything but is good practice. > +1 keeping an eye for dependencies, keep it low and healthy modules. > We got bite in the behind very very hard this week when a very low, > low, very small node module got removed from npm registry, and suddenly our > tool stop installing even using shrinkwrap locks down the version, but if > that version is unpublished. And no it's not a fast process to just a top > level dependency tree on a production/tested software > > npm 2.x will have better support to easily support multiple registers > including "private/enterprise" ones. > > Also we use npm as library, we need to evaluate and update it soon to more > up to date level. > > yep I'm keeping an eye also :-) > > On Wed, Oct 1, 2014 at 6:23 PM, Brian LeRoux <[email protected]> wrote: > > > it is, and as the podcast said, shrinkwrap isn't quite ready for prime > time > > anyhow. I'll be keeping an eye on it (as will others) so we can be sure > to > > take advantage of it when it becomes stable and reasonable to use. > > > > On Wed, Oct 1, 2014 at 3:12 PM, Steven Gill <[email protected]> > > wrote: > > > > > In the past, semver has caused me problems due to having modules npm > > > linked. Ex Running npm shrinkwrap on cordova-lib while i have cordva-js > > > linked will break. > > > > > > Shrinkwrap also requires those dependencies to already be on npm. So > if I > > > reference cordova-js 3.7.0 and it hasn't been published yet, it will > > fail. > > > > > > Overall, I find it to be very annoying. I can follow the instructions > > step > > > by step while releasing to get around some of these problems > (publishing > > > dependent packages first, remembering to unlink) but it just feels > like a > > > waste of time to me. > > > > > > Another problem is if we leave it in master, it will cause headaches as > > we > > > do local dev. Will have to remember to remove it. > > > > > > Pinning seems like much better option IMO > > > > > > On Wed, Oct 1, 2014 at 1:46 PM, Marcel Kinard <[email protected]> > > wrote: > > > > > > > From my scars of the last release, what I'd suggest as closer to the > > > ideal > > > > of "benefits of shrinkwrap with a lower cost" would be to publish to > a > > > > private npm repo and use something like the --registry flag to test. > > > Using > > > > a private registry would also give us the opportunity to wipe any > > > published > > > > packages in case a republish is needed, to avoid bumping the version > > > > numbers. https://issues.apache.org/jira/browse/CB-7550 > > > > > > > > Until we have a private registry for release testing, I agree with > > Steve > > > > that rc's should not be published to npm, and instead use --usegit. > > > > > > > > On Oct 1, 2014, at 4:25 PM, Andrew Grieve <[email protected]> > > wrote: > > > > > > > > > The root of what I meant I guess, was that if shrinkwrap doesn't > work > > > > > without publishing, then let's just publish and don't sweat version > > > > numbers > > > > > jumping by more than one. If we can get shrinkwrap to work through > > > > another > > > > > means (private npm repo?), than that's even better. > > > > > > > > > > On Wed, Oct 1, 2014 at 4:00 PM, Josh Soref <[email protected]> > > > > wrote: > > > > > > > > > >> Steven Gill wrote: > > > > >>> we can test platform rc's with --usegit and > > > > >>> eventually a private npm registry for testing. > > > > >> > > > > >> +1 > > > > >> > > > > >> > > > > > > > > > > > > > > > > > -- > Carlos Santana > <[email protected]> >
