Implementing Node.js

Indigo

0x62 Node.js 'server' option which runs/restarts a node program (e.g my usecase for this would be running something like https://cube.dev as a service).

I think there are two aspects to a node.js integration:

provide access to a range of node versions, as-in, just have the chosen version in your $PATH ready for use
the ability to have a service which starts / stops an arbitrary server (eg https://cube.dev). This would start/stop along with the other services in a stack

When I look at https://volta.sh, I start thinking it feels like the node.js integration could be a bit of a slippery slope — how far should it go? Would it need more than the above bullets?

0x62

So for me personally, I wouldn't use this for local node development. I much prefer managing node versions with NVM, and when I'm working I want to be in a terminal. Plus with NVM I can just create an .nvmrc file in each of my projects and everything gets set up automatically as soon as I cd.

What I would use this for is long-running services I want to start once a day and forget about (e.g. a job worker, cubejs etc)

Indigo

Ah interesting, that's helpful guidance.

I'm interested in feedback from others on this — would you use it the same way?

pocahontasdividends

volta looks overwhelming and cluttered with unnecessary function, all I would expect from indigo is satisfied by the bullet points, the rest could be covered by putting scripts into package.json (and possibly hooked into by indigo to execute those)

Indigo

Sounds great! I can certainly add those two bullet points (says I, foolishly ignoring the likelihood of unforeseen complexity jumping out at me haha).

I've not done node in a while so am a bit out of touch — can you tell me which versions you'd like to see included?

Regarding implementation, I wonder if there should be two services; one is a new "Nginx" service, in various versions, and the second would be a generic "Runner" service which starts any long-running process when the stack starts and quits it when the stack is shut down. The runner idea could probably be quite handy beyond node.

pocahontasdividends

Indigo generally I either grab latest or LTS, but others would probably want to have the full spectrum, I believe nvm and n (https://github.com/tj/n) just pull the list from nodejs' website and give the user the choice which one is going to be downloaded, maybe would be useful to be able to have multiple nodejs services too, since e.g. you could have frontend and backend process'

regarding the runner, at first I was confused what the difference would be, but then realized the nodejs service would purely expose that nodejs in that path I assume; wouldn't it be easier if the nodejs service does both? select the version and then whatever it's supposed to run (possibly with the package.json parsing mentioned above), maybe with some kind of restarting conditions dropdown too

that way you could choose nodejs for backend with version X and it running "dev" from package.json all in one, then have the same for frontend

Indigo

pocahontasdividends realized the nodejs service would purely expose that nodejs in that path I assume

That's what I'm thinking, yes.

I do still like the generic runner service idea — you could use it to run things other than Node.js stuff, eg php's built-in server, or running Laravel's queue workers with php artisan queue:work.

Also I think running a Node.js app would not necessarily be 1:1 with the Node.js Indigo service — you might want to run > 1 app from the one Node.js service.

However, you make a good point (if I'm understanding correctly); if a stack has two Node.js services, how would a generic runner know which to use? I'm thinking it could have a drop down allowing you to choose one of the existing services in the stack. In the GUI the implication is that you are going to run the app using that service. At a technical level it would actually just mean the chosen service is first in your PATH.

For example, if you have added a Node.js 18..0 service to your stack, you could then add a runner and configure it like this:

Is this anything like you're envisaging?

pocahontasdividends

That feels a bit awkward to me, but I guess it makes sense to split for people that only want nodejs exposed and not run anything, but the UI would need a clear distinction and explanation of why there's a runner and a separate nodejs, I've asked a few colleagues and they felt confused too when I pitched the idea of "runner" and "nodejs" being separate in indigo.

Wouldn't it be better UX wise to have environment and start command as a collapsed option in just regular nodejs - and if it's not defined (or checkboxed?), it doesn't run anything and only exposes nodejs? same for php etc, that's what I'd expect going into that screen

Indigo

Thanks, that's very valuable feedback. You've helped me realise it would not be as clear that way. I'm not sure if there will be any other config needed in the nginx service; if not, what do you think of the following? The start command could simply be left empty if nothing needs to be started.

If you wanted to run two nodejs scripts, I guess you'd add a second nodejs service to your stack?

pocahontasdividends

Indigo if one wants multiple commands they can just combine those with && or just have a longer one in their package.json I assume and yeah alternatively just multiple services to keep it clean, depending on if it maybe needs another nodejs version too.

in terms of things missing; the screenshot doesn't show a dropdown for the nodejs version anymore, that's something that would be definitely necessary (unless it's collapsed into environment?)

Indigo

Good point re &&; I could document that for those not familiar with it.

The screenshot above is of a specific node service, and thus you will have already chosen the node.js version by the time you're seeing this. In other words, in the service list where you see the other services, including various versions, such as PHP 7.3, PHP 7.4 etc you will also see Node.js 18 (18.2.0), Node.js 16 LTS etc You'd then drag your chosen node version service into your rack and that's the version the above screenshot will use to run the command.