Update Node stack to 12, transition 10 to node10 stack
ocdtrekkie opened this issue · 7 comments
I am not in a rush to do this (marking it for vagrant-spk 1.1), but I figured I'd open the issue since people may have comments on it, particularly if they work with Node more than I do. In #242, we determined the "current LTS" would be node and that we'd retain our legacy Node stack, for apps that depend on it, as node6. Presumably then, now that Node's current LTS is 12, we should be planning to transition to it.
-
Regarding Node 12: Sandstorm and Wekan both have/had some rough bits migrating to Node 12, I believe? How soon after an LTS becomes the LTS are we worried about having the stack ready in vagrant-spk?
-
Regarding Node 10: Given above, is the breakage enough there's likely to be apps people want to package which still won't support Node 12? Given the delay in merging the new Node stack, there are probably no existing apps using it. Is there value in retaining it long term as
node10? -
Regarding Node 6: As our "original" Node stack, most Node apps currently in Sandstorm were probably built with this. But how long should we retain it as a vagrant-spk stack? Are there a lot of apps which still cannot work with newer Node versions that we either want to update or package in the future?
One thing that occurs to me; we probably shouldn't do this until node-capnp supports node 12, see:
...otherwise it will not be possible to write apps that talk to the capnp APIs using the node stack.
That seems like a plausible point to wait. (And perhaps that's one of the answers I'm hoping to suss out on this issue: We should support a new node LTS once node-capnp supports it.) I gave myself a tentative six month out target date for vagrant-spk 1.1, so I would think there's a good chance node-capnp will be there before we are?
node-capnp now supports node 12.x (and we're using it in sandstorm itself), so that issue is out of the way.
Note I found that Node 12 crashes on startup if /proc/meminfo doesn't exist: nodejs/help#2099
Placing an empty file at /proc/meminfo is sufficient to work around the issue.
That's pretty irritating to fix with vagrant-spk since it can't modify the package definition file. Can we do that from the Sandstorm side like we did /proc/cpuinfo or is there stuff in meminfo that is risky to share?
Or if this is an actual bug do we just hold for a fix?
There's already a fix in Node: nodejs/node#31477
It looks like it was backported into Node 12.16.2: nodejs/node#32313
So I guess it's fixed already... just not in the version Meteor currently pins.