Upgrading Node.js

[rgoomar]

_45 Upvotes_ So, Node.js now has a fully merged codebase between itself and io.js and they released 4.0 which is meant to be LTS.

Since that will be the continuing track for the future, it would probably be a good idea to upgrade to node v4. But, it will be a large task since there are a lot of changes between 10.40.0 and 4.0.0.

To me, it makes sense to upgrade especially since there are built-in ES2015 features and Meteor 1.2+ is all about ES2015

EDIT: Breaking changes between 0.12 and 4.0 can be found here Breaking changes between 0.10 and 4.0 can be found here

[emgee3]

Fibers' tests fail when run in Node 4.0, at least on my computer. I'm also running El Capitan, so there could be another issue going on.

EDIT: Did some additional testing and created an issue https://github.com/laverdet/node-fibers/issues/242

[Cangit]

Getting on the LTS builds of Node looks like a really good idea for Meteor. (18 months of patches and then a 12 month security and critical bug fix period for a total of 30 months support.)

Its worth mentioning the huge speed and memory gains of Node v4 over 0.10, achieved by a mix of V8 4.5 and improvements to the Node/io.js code base over the last year.

[web-jenezis]

Fibers' tests fail when run in Node 4.0, at least on my computer

I have the same problem. What the highest version of NodeJS we can use with Meteor? I guess 10.40.0?

[dfischer]

+1 this is very much needed and the longer it takes the more hurt it will be

[gitawego]

+1, in meteor world, we can not really benefit the Progress of nodejs :( with the release of meteor 1.2, I hope they could support node 4.0.0. 'cause that would be much faster at server side with native es6 support.

[raix]

+1

[jaskinn]

+1

[benjamn]

I'm also really excited about this, but I'm curious if there are any particular new features that people are more excited about than others. Specific compelling motivations will really help us prioritize this work against other projects!

In my mind the biggest hurdles are getting Fibers to work (unknown difficulty) and getting NPM packages with binary dependencies to update to the latest V8 native embedding API.

[lfilho]

I'm particularly interested in the ES2015 features of Node 4, so I can develop ES2015 code without Babel.js and etc. Right now there seem not to have a good way of doing ES2015 + Meteor.js.

Thanks, @benjamn !

[tacone]

Using ES2015 does not seems to be a good reason, because on when coding on the client, or isomorphic, you're still stuck to babel.

The better reason I see is compatibility with NPM modules. If you look at that, you also have to consider possible incompatibilities, so I guess is a kind of trade-off. Since node is changing very fast, though, I'd suggest to not lag too much.

[seeekr]

@benjamn The real deal here is not and should not really be about features. Node is finally seeing proper updates to its core and is at long last catching up and staying up to date with v8 releases. No matter what those releases bring in features, if we want to follow good modern development and deployment/ops practices and also be a good citizen of the Node community there is no reason to stay behind. We all upgrade all the software that we use regularly, for many good reasons, and now is the time to start moving to Node 4.x and develop plans and systems to make Node upgrades easier and more seamless in the future. The Node and v8 teams are doing excellent work and the Meteor community deserves to benefit from that regularly, now that that has actually become possible and workable.

[rgoomar]

@benjamn There are a lot of performance improvements and if we move to Node 4.x faster, it will allow for us to use the native functions rather than relying on a transpiler for certain functionality.

Also, if Meteor gets upgraded to Node 4x, it should gain more adoption because you can write a blog post about it ;) And if people are wanting to use the latest node and look for a platform or framework to use and they see Meteor is still at 0.10.x, it can make them stray away from it.

[rclai]

@benjamn I was able to confirm that Fibers 1.0.7 still works in Node 4.1.0.

[raix]

1. security
2. Stability (it contains alot of fixes from io.js)
3. performance / es2015 native

(I'm concerned about fibers blocking node upgrading, might be a good idea to start thinking about async support within the next 12month, and get off fibers asap?)

Maybe call 1.2 "2.0" and get it over with (the missing jquery+tracker is breaking things anyways, following semver)

[nicolasparada]

ʕつ ͡◔ ᴥ ͡◔ʔつ

[benjamn]

Just to prevent further speculation, fibers work perfectly well with Node 4.0 and will not be a barrier to upgrading.

[evenfrost]

Would love to see Meteor operating on top of Node.js 4+. It's a bit of a shame that the most advanced JS framework still depends on version of node outdated years ago.

[seeekr]

@evenfrost Just to clarify -- Node 0.10.x was not an outdated version of Node. It is still the version that most production deployments of Node run on and it has been and still is fully supported. Node 0.12.x took years to develop (or rather finish up because momentum of contributions and excitement about it had dried up) and its adoption has also been going slowly, from what I can tell, one reason certainly being that it still did not ship with an up to date version of v8. And only very recently there has been a push towards a new, modern, fully up to date Node release -- led by the iojs team -- which only a few weeks ago produced its first fully Node-compatible release that will also be supported in the long term, Node 4.x LTS (currently at 4.0 or 4.0.1 today/tomorrow -- EDIT: correction, it's at 4.1 atm with 4.1.1 being released right now), with the LTS tag getting officially added in October. So Meteor really did do the best job choosing the appropriate version of Node that was available up until this point. From here on out I'm fairly certain 4.x will be adopted reasonably quickly, maybe and desirably with 1.3 or even with an 1.2.x patch release.

[rgoomar]

Another document to add on to look at. @benjamn keep these changes in mind between v0.10 and v4: https://github.com/nodejs/node/wiki/API-changes-between-v0.10-and-v4

[jperl]

:+1:

[epaminond]

+1

[dalcib]

+1

[guilhermedecampo]

+1

[vamsivarikuti]

+1

Node v4.2.0 LTS is released https://nodejs.org/en/blog/release/v4.2.0/ More details on LTS Support https://nodesource.com/blog/essential-steps-long-term-support-for-nodejs

[aaronjudd]

+1

security, security, security. performance.

[GJean]

+1

[fredevery]

+1

[benkaiser]

+1 fibers needs to be upgraded from 1.0.5 to 1.0.7 to work with nodejs 4.2.1

[ivpal]

+1

[stbaer]

+1

[kimsk]

:+1: Although, nodejs v5 has just been released recently, I like the idea of supporting 4.2 which is a LTS version.

[hlehmann]

+1

[kop]

Ladies and gentlemen, please, if you want to express your support to this issue and don't have much to say, just click "Subscribe" button. Every "+1" you create is just an email spam for everyone subscribed. Thank you.

[bmustata]

+1

[buhrmi]

Our sysadmins are angry with me cause they now have to maintain node 0.10 to run our Meteor apps while the rest of our stack has been upgraded to the latest version of node. It would be really cool if Meteor could be fixed up to support a current version of node. Thanks :)

[meteoro]

+1

[quellhorst]

:+1:

[stefankutko]

+1

[fakenickels]

Any updates on this from MDG?

[Cangit]

Ping @avital @glasser @Slava @dgreensp Is this discussed internally? There has been a eerie absence of core devs communicating with the community. Any reassurances would be very welcome.

[glasser]

@benjamn is a core dev :)

[ghost]

+1

[dotnetwise]

+1

[DSpeichert]

+1

[Aralun]

@benjamn One of my bother is some inconsistencies between Node 0.10.40 with Babel polyfills and modern browsers. Given:

const symType = typeof Symbol()

symType will be 'symbol' on modern browsers and recent Node, and 'object' on Meteor server-side and older browsers (Babell polyfill).

[zarvox]

@benjamn A couple high-value things which we'd appreciate that appear to need a node upgrade are:

1. Working forward-secrecy in TLS connections. Node 0.10 doesn't set up the ECDH and DH params with openssl, so no ciphersuites supporting forward-secrecy will be chosen, so none of the TLS connections have forward-secrecy. This is fixed in 0.12 and above, if I remember correctly.
2. Support for node's --perf_basic_prof (which landed in 0.11.13) or ideally --perf_basic_prof_only_functions (which is available in v5.x and might land in v4 LTS Soon™) so we can have JS symbols in flamecharts when profiling server-side or stacktraces if we want to do post-mortem debugging with coredumps.

[rgoomar]

Going forward, I think the platform should try to stay up-to-date with the latest LTS releases of Node. So, right now the 4.2.x releases are LTS and it makes sense to upgrade to that. It can be a nice benefit for enterprise users who want to make sure they have the most stable and supported version of Node. Those are just my thoughts.

Is there any update on where this is on MDG's roadmap @benjamn? It's been awhile since you have chimed in. I know you mentioned you wanted to get an idea of why people want to upgrade and I feel as though a lot of good reasons have been posted here already.

[4Z4T4R]

We're also on the fence with Meteor until we get confirmation about when Node 4.2.x will be the standard in Meteor. Please chime.

[BodhiHu]

+1

[thsowers]

+1