[UX-284] Updated dependencies and update of node and npm mvn versions #129
Conversation
|
When building via mvn, do we turn off the progress bar? I remember something about that improving performance on newer npm |
|
@sophistifunk yeah it speeds it up a bit ... we don't turn it off in the parent pom profiles but I will add that when updating it with the newer versions of node and npm. On the time test I did ... turning off the progress bar improved speed by > 10% and < 20% ... so not enormous. ( also tried ied and nmpm ... a lot faster but didn't seem to resolve the packages properly ... so no use) |
|
What's actually interesting/strange here is that the CI build for this (build 312) finished in 12 mins Vs ~ 17 mins for other PR builds (using the older npm and node). I wonder is the newer version actually faster in terms of processing, but more chaty wrt the npm registry or other, causing it to be slower on machines that don't have an amazon-like connection to the WWW. |
|
Okay ... I found the reason why js-builder:0.0.27 was needing a newer version of npm. I fixed that, which means this PR no longer sets the npm and node versions for the mvn build. |
tfennelly
force-pushed
the
updated-js-libs-and-node
branch
from
8f5a27c to
f964fa6
Compare
…sions of node and npm I fixed the issue that was causing js-builder to require a newer version of npm. The issue was that it was specifying a Browserify transformer by name Vs resolving locally and passing an instance. By-name resolution looks for the package in the top level of node_modules, causing it to bomb with older versions (that don't flatten the tree).
tfennelly
force-pushed
the
updated-js-libs-and-node
branch
from
f964fa6 to
177e877
Compare
|
Deps changes look good to me 🐝 |
Related to issue # UX-284.
Note:
mvn clean -DcleanNodebefore building.npm install. But apparently the newer versions also fix some major package resolution issues, so prob best that we use it.@reviewbybees