Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update Node stack to 12, transition 10 to node10 stack #255

Closed
ocdtrekkie opened this issue Feb 3, 2020 · 7 comments · Fixed by #331
Closed

Update Node stack to 12, transition 10 to node10 stack #255

ocdtrekkie opened this issue Feb 3, 2020 · 7 comments · Fixed by #331

Comments

@ocdtrekkie
Copy link
Collaborator

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?

@ocdtrekkie ocdtrekkie added this to the vagrant-spk 1.1 milestone Feb 3, 2020
@zenhack
Copy link
Collaborator

zenhack commented Feb 3, 2020

One thing that occurs to me; we probably shouldn't do this until node-capnp supports node 12, see:

capnproto/node-capnp#52

...otherwise it will not be possible to write apps that talk to the capnp APIs using the node stack.

@ocdtrekkie
Copy link
Collaborator Author

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?

@zenhack
Copy link
Collaborator

zenhack commented Mar 21, 2020

node-capnp now supports node 12.x (and we're using it in sandstorm itself), so that issue is out of the way.

@kentonv
Copy link
Member

kentonv commented Apr 11, 2020

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.

@ocdtrekkie
Copy link
Collaborator Author

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?

@ocdtrekkie
Copy link
Collaborator Author

Or if this is an actual bug do we just hold for a fix?

@kentonv
Copy link
Member

kentonv commented Apr 11, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants