adding node.js for building web server

[jacekkolasa]

Feature idea summary

We need node.js to build the new, WIP dashboard app written with React and Webpack - #6515

Expected behavior

During Agent build process, before the web server configuration process takes place, the installer script should

• run npm install in /web/gui/dashboard/ directory
• run a .js script, let's say: /web/gui/dashboard/build-dashboard.js
  The content of build-dashboard.js will be written in separate PR - [WiP] React dashboard #6516

Minimal Node version is8.16.0, but latest LTS is preferred

[paulkatsoulakis]

Regarding our current CI infrastructure, here's what versions supported:
https://docs.travis-ci.com/user/languages/javascript-with-nodejs/#specifying-nodejs-versions

Note: The link above provides other details too that are not applicable for the moment.

[Ferroin]

Just a thought, but might we want to consider bundling a prebuilt version of the Web UI in the sources, kind of like what a lot of JavaScript libraries do? That would provide two big advantages for end-users:

• Build times would be shorter. Not sure how much this would help, but I would not be surprised if it's multiple minutes difference on mid-range systems, and possibly dozens of minutes on low-end ones.
• Users wouldn't need to install Node.js for the build process unless they specifically wanted to rebuild the Web UI. Sounds stupid, but Node is not exactly small, and it's not by any means going to be universally available on systems that would want to build Netdata.

[jacekkolasa]

@Ferroin big thanks for bringing it up! The build time can definitely last more than 5 minutes on mid-range system, and node_modules directory can grow in size up to 200-300 MB (which needs to be downloaded). Perhaps we should rethink this. I am thinking about the possibility of having Dashboard as a separate repository, and publishing dashboard.js via CDN and also as a NPM Package. @paulkatsoulakis @cakrit what do you think?

[Ferroin]

I think having the dashboard as a separate package in the official Netdata repositories would be good, especially as it's likely to get somewhat bigger with the React rewrite. Not sure that having it available via CDN makes much sense though (most Netdata dashboard usage is likely to be internal to a company, and I suspect that, for security reasons, most people running it internally will want it to be served 100% locally).

[jacekkolasa]

@Ferroin thanks again for the input! We have a different idea - we can push the compiled .js code directly to the same repo. Travis will also compile the code and validate if the checksums are matching, to make sure the compiled version matches the source. Very similar checks are now implemented in our Travis scripts (it validates if the content of /src/dashboard.js matches the compiled dashboard.js).
We will check how long does it take for Travis to compile the new Dashboard, and if needed, we'll run that additional check only when Dashboard source code/compiled code has been changed.

Unfortunately that means that for now we'll have Dashboard in the same repository, but we can discuss other possibilities later.
@Ferroin does that sound good to you?

[Ferroin]

@jacekkolasa So, I think I might not have been as clear as I could have been. I'm not really all that worried about whether the dashboard is in the same GitHub repo as the rest of Netdata or not. What I, from both an end-user and sysadmin perspective, and worried about is ensuring that:

• The Netdata core and the dashboard can be built and installed completely independently of each other (this is technically currently the case, you can install just the core or just the dashboard if you want). Ideally, this would be extended to the official Netdata packages, but that's somewhat orthogonal to the process of rewriting the dashboard (though I feel that now is probably the easiest time to do so).
• If you want to install both from source (for example, using kickstart.sh), you don't have to install Node.js to do so.

[jacekkolasa]

@Ferroin From my perspective you were clear from the beginning. :) What we plan to do is to have the exact same behaviour as it is now. Node.js will have to be installed only by FE devs (globally, on their machines), and it will be used also by Travis pipeline. End-user will not have to be aware of those changes (only exception is if they have been overriding internal .js logic stored in window.NETDATA methods)

[jacekkolasa]

closing, because this issue is not valid anymore