Yeah, seems like it might be worth while to seriously investigate migrating to yarn if that gets us a consistent build.
On Mon, Oct 2, 2017 at 11:37 AM, Otto Fowler <[email protected]> wrote: > [WARNING] npm WARN deprecated [email protected]: ...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 ([email protected]) 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, [email protected] <[email protected]> > wrote: > > > Hmm, 0.4.1 built fine for me. > > > > Jon > > > > On Mon, Oct 2, 2017 at 10:44 AM Casey Stella <[email protected]> > 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 > > > >
