+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 <b...@brian.io> 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 <stevengil...@gmail.com>
> 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 <cmarc...@gmail.com>
> 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 <agri...@chromium.org>
> 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 <jso...@blackberry.com>
> > > wrote:
> > > >
> > > >> Steven Gill wrote:
> > > >>> we can test platform rc's with --usegit and
> > > >>> eventually a private npm registry for testing.
> > > >>
> > > >> +1
> > > >>
> > > >>
> > >
> > >
> >
>
--
Carlos Santana
<csantan...@gmail.com>
