metron-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Otto Fowler <ottobackwa...@gmail.com>
Subject Re: [DISCUSS] Build broken due to transitive dependencies
Date Mon, 02 Oct 2017 15:37:07 GMT
[WARNING] npm WARN deprecated bower@1.8.2: ...psst! Your project can stop
working at any moment because its dependencies can change. Prevent this by
migrating to Yarn:
https://bower.io/blog/2017/how-to-migrate-away-from-bower/


On October 2, 2017 at 11:29:50, Casey Stella (cestella@gmail.com) wrote:

Ok, I can verify that 0.4.1 did build for me (took forever with vagrant
running too). It's probably due to a dependency that was added after the
release (whew!). Hmm, now that I've build master again, the problem seems
to have gone away and the build is working again.

On Mon, Oct 2, 2017 at 11:04 AM, Zeolla@GMail.com <zeolla@gmail.com> wrote:

> Hmm, 0.4.1 built fine for me.
>
> Jon
>
> On Mon, Oct 2, 2017 at 10:44 AM Casey Stella <cestella@gmail.com> wrote:
>
> > Ok, the build is broken in metron-config due to some transitive changes
> > that happened in npm-land:
> >
> > [INFO]
> >
> > /Users/cstella/Documents/workspace/metron/fork/incubator-metron/metron-
> interface/metron-config/node_modules/toposort/index.js:32
> > [INFO] throw new Error('Cyclic dependency: '+JSON.stringify(node))
> > [INFO] ^
> > [INFO] Error: Cyclic dependency: "[object Object]"
> > [INFO] at visit
> >
> >
(/Users/cstella/Documents/workspace/metron/fork/incubator-metron/metron-
> interface/metron-config/node_modules/toposort/index.js:32:13)
> > [INFO] at visit
> >
> >
(/Users/cstella/Documents/workspace/metron/fork/incubator-metron/metron-
> interface/metron-config/node_modules/toposort/index.js:48:9)
> >
> > Evidently one of our transitive dependencies has changed and we have
> ended
> > up with a cyclic dependency. I'm not sure where or why yet, but I
> believe
> > this breaks both master and our 0.4.1 release (I haven't confirmed this
> > yet, but I strongly suspect).
> >
> > While the good work of tracking down this specific error is done, I'd
> like
> > to bring up a broader discussion point: our practice of not fixing
> versions
> > for our node dependencies. This is, in effect, causing a few problems:
> >
> > - We do not have a consistent, repeatable build.
> > - We set ourselves up for possible license violation without knowing
> > about it (a transitive dependency changes its license)
> >
> > As we stand, we have a release which doesn't not build after we have
> > released it and tested it. It seems to me that we should at a minimum
> as a
> > stopgap:
> >
> > - fix the versions of our dependencies so that they are in a working
> > state
> > - consider a point release to get a working build.
> >
> > I guess my questions to those of us with more javascript and UI
> experience
> > is as follows:
> >
> > - Does fixing the version of our dependencies actually fix the problem
> > transitively?
> > - IF not, then how do we get a version of a build which is consistent
> > and repeatable and does not expose us to downstream licensing issues?
> >
> > Thanks,
> >
> > Casey
> >
> --
>
> Jon
>

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