Meteor: 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 :)

[Stamper-repo]

+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

[jfrolich]

+1

[D1no]

+1 Its just pain to integrate meteor in a Node v4 test environment. And we would like to have the performance improvements!

[chriswessels]

+1

[BodhiHu]

Em... so anyone know when will meteor upgrade to the latest Node ? :expressionless:

[JWo1F]

+1 I want to use node v5.3.x

[faddat]

What is the status of the transition? Is there a jumping-off point where someone could begin to explore getting it done?

I ask because clearly stating that jumping off point, would seem to me to be the most prudent way to begin to approach what is certain to be a complex and challenging transition-- I personally don't even have the skills to pull it off, but I know that for anyone with those skills, this information is crucial in formulating a plan to tackle this.

[singggum3b]

:+1:

[masavini]

+1 for LTS

[sys13]

I'm having to patch node with Intl as there is no Intl support in 0.10. Node 4 has a more complete implementation.

[v3rron]

+1 for LTS

[balupton]

Module author here, and as soon as I publish code that doesn't work in node 0.10, I get a lot of meteor users filling issues, which is a real drag as I would like to drop node 0.10 support.

Is there a specific set of todos here? What can the community do to help make this happen? Perhaps I can help?

---

Regarding the continued +1s

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.

https://github.com/meteor/meteor/issues/5124#issuecomment-154230021

[marbemac]

Two issues that we have run into, that I don't see mentioned above (it's a long thread, apologies if I missed it):

1) Certain modules we are trying to use, like the VM module, are unstable in node 0.10.x, and stable in later versions. There are security vulnerabilities as well.
2) Meteor is all about isomorphic JS, and we should ideally be able to use the same code in the browser and the server. Browser implementations of certain modules are diverging from node 0.10. For example, the API for the URL module in browsers differs from node 0.10 (https://nodejs.org/docs/v0.10.0/api/url.html), which led to weird bugs and inconsistencies we experienced as our client and server (which share the same code) were dealing with different URL apis. This is fixed in newer versions of node.

Also, ditto @balupton above, but from the other side. There are several NPM packages we'd like to use but can't because they require > node 0.10.

[georgiosd]

What's worrying me is the lack of official comment from the team on such an important issue, even if it is to say "we're thinking about it".

[balupton]

From the module author perspective, it turns out babel compilation for node 0.10 support can break ESNext/ES6+ capabilities, which is not desirable: https://github.com/bevry/base/issues/20

So I'm left wondering then, at least from my responsibility as a module author, if I published normal babel compiled code (ES6+ compat, breaking node 0.10 compat), and then told Meteor users to include the babel polyfill or the babel runtime, is that an option they would do?

Are there many Meteor users already including such polyfills? Is including ES6 polyfills something the community does? or is open to?

[danjenkins]

Is there any movement on this? I feel _very_ uncomfortable starting a new project using meteor as I can't use LTS node (v4.2.x) - If I knew this is coming soon etc, then I'd feel happier about developing something knowing it was coming soon. At the beginning it was said that it would be dependent on fibers but that's now working with v4 so I'm a little lost as to why this hasn't moved forward?

[appinteractive]

:+1:

[stubailo]

When we do this, we should consider switching Windows to 64 bit node: https://github.com/meteor/meteor/issues/6062

[nathan-muir]

@stubailo I understand that there's more than just getting Meteor _running_ on Node v4; But I've done a bit of hacking anyway just to try it out.

If meteor did decide to upgrade to node v4 for 1.3/1.4+, it seems any current package with a binary-dependency would need to be marked as unsuitable & re-published/updated.

If it helps for when MDG do the transition, there were a few gotchas along the way:

• Building the dev-bundle & child NPM packages failing, without informing you of the parent package.
  
  
  
  • Thank you libraries.io for mapping dependents. eg. runas is used by pathwatcher
  
  
• tls doesn't send SNI by default anymore (causing issues connecting to packages.meteor.com). This wasn't documented in any of the Node release notes...
  
  
  
  • Thank you wireshark... without you I would have given up...
  
  
• isopack has a bug instantiating new Buffer() with source maps, which is currently failing silently on node v0.10 (I think??)

If anyone would like to try it out (only verified on OS X 10.11):

#!/usr/bin/env bash
git clone [email protected]:nathan-muir/meteor.git meteor-node-v4
cd meteor-node-v4
git checkout -b meteor-1.2-with-node-v4

# We need to build Node v4.2.6 from source, you'll only need to do this once...
./scripts/build-node-for-dev-bundle.sh

# If cordova-lib fails to download, try uncommenting these lines
# curl -O "http://com.meteor.static.s3.amazonaws.com/cordova-lib-1512fc069c7ea51c7a112cf14a8d93d69726a6f7.tar.gz"
# sed -ir "s http://com.meteor.static.s3.amazonaws.com $(pwd) " scripts/dev-bundle-tool-package.js
./scripts/generate-dev-bundle.sh

# need to link non-core packages or we'll have lots of failures
ln -s packages/non-core/npm-bcrypt packages/npm-bcrypt
ln -s packages/non-core/npm-node-aes-gcm packages/npm-node-aes-gcm

# Link as "meteor-node-v4" for testing and fun...
ln -s "$(realpath ./meteor)" /usr/local/bin/meteor-node-v4

meteor-node-v4 test-packages

[balupton]

@nathan-muir _hugs_ :+1: :100: great work! :clap: :cake:

[faddat]

@nathan-muir _applause_ indeed.

[stubailo]

Wow, amazing! Thanks!

[TimHeckel]

+1 @nathan-muir, wonderful

[benjamn]

@nathan-muir really appreciate your findings!

[balupton]

So I guess the next step is having the meteor team merge it in and do the necessary tweaks? If so, can the meteor team provide an ETA?

[avital]

While we all are very excited about the prospect of upgrading Node, we aren't looking into this as part of the upcoming Meteor release (1.3). There's already a bunch of changes in this release (modules, mobile improvements, testing, ...). We'll probably look at upgrading Node in the version of Meteor that comes after 1.3. I can't give a time estimate.

[laosb]

Could we first make it easier to replace Node in meteor?

For example, we may have a command line option says --use-node-in-path

That can make us easier to have a look what we have to do in this transition.

And maybe print a log(warning) instead of stopping the bundle from running when we use a Node which is not officially compatible?

[avital]

As described on the thread, Meteor won't work as-is with a different version of Node, for a decently long list of issues.

If you really want to you can check Meteor out from source, run it once (to populate the dev_bundle directory), then change dev_bundle/bin/node to be a symlink to whatever node executable you have.

[danjenkins]

@avital @benjamn I don't want to be 'that guy' that we all hate so I'll ask again, what can we do to help you? @nathan-muir has put a lot of work into his findings in upgrading Node. It pains me that I cannot with good conscience start developing anything new with Meteor. I will not start developing anything new that can't run on Node LTS - for all the reasons why theres an LTS in the first place; let alone all of the performance benefits and stability fixes in Node 4.

If this isn't a goal of 1.3 because of a 'decently long list' of issues - can these be made into github issues and tagged with node-upgrade or something so that 1) people can contribute to those fixes and 2) we as the community get some sort of visibility into the project and what's happening in relation to being able to upgrade Node. I admit I haven't been using Meteor for long, I'm not a prominent member of the Meteor community but I'm sure everyone would love more visibility - wouldn't you love to put up issues that were stopping any chance of upgrade and have people fix them for you? We can't do this without you telling us what those issues are.

Walled Gardens don't let flowers blossom (Or something like that)

Thanks, and sorry if I came across as 'that guy' - it's not my intention.

[laosb]

I'm totally with Dan.

It's truly important for Open Source project users to decide the project's
future, which is proved by the io.js movement. Meteor is in a similar
situation now, with a lot of long-history, delayed-but-important issues to
solve. MDG's work should be more open to public.

[avital]

Upgrading Node is the top priority after shipping Meteor 1.3.

You can help us -- follow @nathan-muir's steps and see if anything else is missing. If you find additional missing steps, please comment on this thread.

We can't catalog a list of tasks to make the upgrade happen until we know what all of the blockers are.

The first thing we'll do before working on Meteor 1.4 is to look at this thread and start working from comments from community members.

[livimonte]

+1 For LTS

[katopz]

thx @avital for update, also @nathan-muir for great finding. :+1:

[laosb]

So which version we're going to move to? 4.x (LTS) or 5.x (Stable)? Should we
follow a certain release tree (LTS or Stable)?

On Feb 6 2016, at 2:47 am, Avital Oliver <[email protected]>
wrote:

Upgrading Node is the top priority after shipping Meteor 1.3.

You can help us -- follow @nathan-muir's
steps and see if anything else is missing. If you find additional missing
steps, please comment on this thread.

We can't catalog a list of tasks to make the upgrade happen until we know
what all of the blockers are.

The first thing we'll do before working on Meteor 1.4 is to look at this
thread and start working from comments from community members.

—
Reply to this email directly or view it on GitHub.

[avital]

We plan to go with LTS versions of Meteor dependencies when available, at least for Meteor 1.4. Then future versions of Meteor can use newer versions of dependencies.

[livimonte]

Node v4 i believe, because v5 has no LTS. Look at oficial schedule: https://github.com/nodejs/LTS#lts_schedule

I'm very happy with this priority, v4 has important improvements of security and performance.

There is a launch date of Meteor 1.3? Any idea?

[avital]

@livimonte Probably later this month. But that won't come with updating Node. That will come in Meteor 1.4.

[livimonte]

Nice,
Thanks @avital.

[D1no]

I would much rather see the stable branch in meteor. Node is an essential component and from my perspective, the node committees LTS decision was a quick shot to calm everyone down after the node-io merger.

Going for stable and may staying on the next upcoming LTS.

[benjamn]

@D1no fwiw, the work we need to do to support publishing binaries for multiple V8 versions will make it substantially easier to upgrade Node in the future. Once we're on Node 4, upgrading to 5 (or 6), when they're ready, will be much easier.

[D1no]

@benjamn this is more of a "Meteor Selling Proposition" one: Looking at the infrastructure I face on consulting jobs, node v5 is well accepted and implemented as a result of the quick v5 release after the initial LTS, because all of them want to make their system future proof.

What's their reasoning:
The next LTS starts in october (2016-10-01) based of the v5/6 stable starting in april (2016-04-01). So instead of going back to LTS v4 (two versions!), which is implicitly replaced in three months, they are on stable to than lock-in onto the next "real" LTS for good - which is well supported into 2018.

This has a lot to do with samver confusion about upwards compatibility from 4 to 5 to 6. See on old Reddit of the v5 release:

I dislike they jumped from 0.1x (and io.js) to 4 and a months later the realise v8 semver is 5 and jump to 5 - stupid. They could have though about version numbers last months, and choose 5.

Thus, teams are scared to have to rewrite packages for the next LTS in just a few month and are already on stable. So I'd wish Meteor would pull along.

1. Internal packages are developed against v5 and people are unsure about downwards compatibility, maybe even upwards compatibility to LTS. The front end space is generally on stable.
2. There is a psychological Infrastructure-Argument of "Meteor runs on Node v4" vs "Meteor runs on Node v5/6" when project teams are already getting ready for Node v6 ("oh man, we just got rid of legacy software"). "Meteor runs on stable, targeting the next LTS, and is downwards compatible to your Node v4 packages/infrastructure" sounds much better and also suits Meteor as modern tech much better.
3. As I see it, Meteor is not getting an upgrade until April. Logistically, targeting stable is already the next LTS (see nodes release cycle).

Node really messed up their samver-system.

[livimonte]

I also agree with @benjamn, after migration to v4, the next will come much faster.

And better to have v4 in two months than the V6 in four, five months or more.

Please note that all migration work for v.5 / 6 should happen in the core of the Meteor and much of their dependencies and packages in the atmosphere and npm. And even v6 being released in April, it will still take time for improvements and bug fixes.

[D1no]

@livimonte Well, my point is to go stable now to avoid an unnecessary, additional infrastructure update over two versions.

Rooting for v4 will not get you an upgrade into meteor any faster. Just more people will wait until meteor is on the "real" LTS at the end of the year. Two samver's in 8 month's, from .10 to the old v4 to v6... not fun for enterprise.

[lscordilis]

+1 this is absolutely necessary moving forward. Many features that were peripheral and unstable in 0.10.40 are now default in Node v4 LTS. These include, but aren't limited to

Native cluster support - which large scale production apps are in desperate need of.
vm - far more useful than people give it credit for. The 0.10.40 version is not nearly secure enough for use in production environments, and I would love to sandbox some code in my apps.

I know Meteor has upgraded to ES6, but having the support of the latest node modules in ES6 would greatly improve the server-side Meteor experience, I feel.

[laosb]

So the problem is that, is targetting v4 or v5/6 costs same effort or time?

I guess targeting v5/6 is a better solution. v4 and v5/6 have many
differences, but it doesn't means we'll have more difficulties in migrating to
v5/6 than v4. v5 is stable now in fact, v4 as a LTS version doesn't mean more
stable, but means will be stable in a longer period.

On Feb 11 2016, at 1:52 am, Livingstone Del Monte
<[email protected]> wrote:

I also agree with @benjamn, after migration to
v4, the next will come much faster.

And better to have v4 in two months than the V6 in four, five months or
more.

Please note that all migration work for v.5 / 6 should happen in the core of
the Meteor and much of their dependencies and packages in the atmosphere and
npm. And even v6 being released in April, it will still take time for
improvements and bug fixes.

—
Reply to this email directly or view it on GitHub.

[livimonte]

Well, V6 now is the dream. But has some points to see before this decision.

For instance:

Security, is now more important which 2 upgrades in infrastructure in this year?
Which dependences are necessary or unnecessary with v4 and v6;
Diference of effort;
Measuring the impact of v6 in communit and estimate time for upgrade of all needed dependences.
Even v6 being released in April, it will still take time for improvements and bug fixes.
Estimated Launch date with v4 and v6.

Let's show our doubts and hear the Meteor team.

Best,

[Cangit]

First of all thanks to @benjamn and @avital for joining the conversation. Its very appreciated.

To clarify on the 4vs5vs6 Node discussion,
Right now, the changes between Node5 and the upcoming new LTS Node6 is a deprecation patch for a feature that was decided to be deprecated in 2011, and two patches arguably not really semver-major.
https://github.com/nodejs/node/pull/5049
https://github.com/nodejs/node/pull/4098
https://github.com/nodejs/node/pull/3793

So the argument that Node6 needs time to mature is not a solid argument. It's important to know how Node is doing their versioning. Every patch that is not a BC-break will land in Node5. So the only patches that will differ on Node5 and Node6 when released will be BC-breaking patches and v8 bump. Considering how strict they are on their BC most of them will likely be spec compliance, speed improvements, security enhancements or downright bug fixes. We are working with semver here, this is not traditional version numbers that indicate major changes to the code base.

[laosb]

Thanks all. Meteor China Community is having a vote on it, and will have a
result tommorrow.

Detailed & Original Vote:

您希望 Meteor 升级到 Node.js 的哪一个版本

• v4.x
• v5.x/6.x

Voters can choose only one option.

[dingyiming]

+1 支持Meteor升级node 到 v5.x/6.x

[ndarilek]

Glad to see this happening. This morning I attempted to use the web-push NPM module to implement browser push notifications, and it appears to use functions from crypto not included in Meteor's current version of Node.

Worked around the issue by running the module in a single-purpose microservice that performs the push based on payloads POSTed to it, but it'll be nice to run the code entirely within Meteor and only break it out if performance requires it.

[laosb]

OK there comes the result of the vote in Meteor China Community. Due to the time of the vote, we only collected 10 persons' views. Most of them are familiar with Meteor itself and have some experience in building production apps with Meteor.

8 persons (including myself) hope we can move to 5.x/6.x versions of Node.js, in which 6.x are going to be in next LTS.
2 persons hope we can move to 4.x of Node.js, which are in current LTS.

[lscordilis]

That vote does make sense. Given the Node release schedule, v6 will be in LTS by this coming fall.

However, v6 will not be stable until April. I'm not aware of all the details concerning the differences between v5 and v6, but I think if Meteor is to upgrade Node in the next month, it might be better off sticking to v4 LTS and upgrading to v6 closer to the end of the year. By that time, everyone should be familiar with the new API, and the transition won't be as jarring. That's just my two cents, though. I work on Meteor production apps, but I'm not nearly an expert enough in the Node foundations of Meteor to make serious judgments.

[laosb]

To be honest, it's a matter of Good for now or Good for future. That's really a not very important question, because if we doesn't use next LTS tree for now, we'll do it in the future.

[285858315]

v4.x +1

[balupton]

Regarding the v4 vs v5+ argument. v4 is the LTS. It is also important to note the rarity of encountering any of the v5 breaking changes, which are all edge cases that _can_ break for _some_ people, rather than cases that _will_ break for _many_ people (such as the 0.10 to 0.12 changes).

Meaning unless someone was doing something undocumented or deprecated, which has likely already been fixed by the outside meteor world, then there should be no quarrels here in easily replacing v4 with v5. We aren't talking months of additional investment here. Months are only taken from getting from 0.10 to 0.4, after that the upgrade from v4 to v5 should take significantly less time.

Let's not forget that v4 is still LTS for the next year and a half! It's not like it is expiring anytime soon. Whereas v5 is still changing, and v6 is still not even released yet.

[balupton]

With that all in mind, the question really needs to be, not shall the move be to particular versions like v4 or v5 or v6, but which stage of support should meteor use for its node release: LTS or Stable.

In other words, should they target LTS releases until the new stable comes out, then move to that (before it gets LTS). Or should they always just use the current LTS release, until the next LTS release is out, and use the cross-over of the LTS releases to move over.

Targeting Stable of LTS seems dangerous for a project like meteor. LTS is LTS for a reason, and there is already enough overlap between LTS releases while they are LTS releases to move things over.

Let's also not forget that Stable releases are the new releases, whereas LTS releases in their +6 months gestation from the initial Stable release to the LTS release already get battle tested and fixed and corrected by the community in that time. So by the time a node release reaches LTS, the eco-system will be more stable for it than at the time of the initial Stable release of the same node version.

[laosb]

I'm totally with you in the real situation of this question, that's we're
selecting stable or LTS.

Stable means more active development, but LTS means only fixes will be
applied.

On Feb 16 2016, at 8:29 am, Benjamin Lupton <[email protected]>
wrote:

With that all in mind, the question really needs to be, not shall the move
be to particular versions like v4 or v5 or v6, but which stage of support
should meteor use for its node release: LTS or Stable.

In other words, should they target LTS releases until the new stable comes
out, then move to that (before it gets LTS). Or should they always just use
the current LTS release, until the next LTS release is out, and use the cross-
over of the LTS releases to move over.

Targeting Stable of LTS seems dangerous to me for a project like meteor. LTS
is LTS for a reason, and there is already enough overlap between LTS releases
while they are LTS releases to move things over.

—
Reply to this email directly or view it on GitHub.

[gunarsritins]

I think using LTS is a better idea. The next LTS release is in the fall, so Meteor should target v4 in the summer.

[martinheidegger]

Just to pitch in my 2cnt: Meteor until recently didn't enjoy a lot of the npm goodies. The LTS support is more important for the packages that rely on c bindings than it is to anything else. Since meteor tries to jump on the npm wagon it is my recommendation to stay with the LTS branches since the likelihood of packages with c bindings to brake is rarer.

[maxnowack]

The best option in my opinion is, if the user could decide which version should be used. However, the implementation would be very complex or even impossible.
As long as meteor doesn't support different versions of node, meteor should use LTS.

[lsunsi]

+1

[dotnetwise]

+1 what? Upgrading to a certain version is way more important discuss than vague and useless +1 comments. So stop spamming and contribute with your objective/subjective opinion about the version to upgrade to.

[4Z4T4R]

Per @avital on Feb 5, "You can help us -- follow @nathan-muir's steps and see if anything else is missing. If you find additional missing steps, please comment on this thread."

Keep in mind that many people have their eyes and attention spans fixed to this thread, so let's encourage those of us with the deep interest to take @avital's advice and utilize this space to do two things well:

1. Follow @nathan-muir's steps
2. Comment on this thread with blockers or ideas relating to step 1.

Perhaps it would be wise to open a new thread for each major version of Node under consideration so the steps can be reproduced for each respective version now or in the future, but here, we should consider v4 and post only what will help us understand the technical nature of the situation and steps for moving forward.

Thank you, and great work!!

[laosb]

For now, maybe v4 is a good start. That's a good solution.

[laosb]

What we may need to solve, is remove the babel procedure for server code. Will this make the build progress faster? Looking forward to it.

[StephanGeorg]

+3

[TimoRuetten]

+2

[martpie]

My concern is not really _what_ will be released, but _when_. I prefer to have the LTS in a few months than V5/6 in 6 months. And it appears that this won't be done for meteor 1.3, but maybe in 1.4, which will be released... well, we don't really know.

[jiangtao]

+1 I hope Meteor can upgrade Node to V5.x. Because of ES2015, I can use more futures to improve my development efficiency.

[appinteractive]

I agree with @jtHwong as I read from MDG that Meteor wants to be the cutting edge development platform. ES2015 is here the way to go and I mean not through Babel (on the server). As v5 will become the next LTS and is already out we should really stick to v5 in my opinion.

[gunarsritins]

@appinteractive According to https://github.com/nodejs/LTS v5 will be abandoned in a few months, and v6 will be a separate thing with a Stable period overlapping that of v5. Also, according to https://kangax.github.io/compat-table/es6/, v4 and v5 mainly differ in support for the spread operator -- a difference of just 5 percentage points.

[D1no]

Yes, it does not make sense to go back to v4. I already elaborated the situation a few comments above:
https://github.com/meteor/meteor/issues/5124#issuecomment-182459156

[appinteractive]

@backdate thanks for correcting me, I was thinking of v6 and not v5. Is there some information about backwards compatibility for v6? Because we have to quickly update when choosing v5 I guess.

[balupton]

Unsubscribing from this conversation as it is going nowhere useful.

There seems nothing left to be said on this (upgrading meteor's node version), only things left to be done (someone does it and core merges it), which will occur soon enough (after 1.3 release).

As said before, the question is not about targeting versions, but about targeting LTS or Stable. Saying +1 for v5 or +1 for v4 or +1 for v6 is useless distraction, no matter how many times one utters a version, versions will still be meaningless targets.

[Fishrock123]

Haven't read though this but would like to try to clarify from the node core team (which I am part of):

Stable: new one every 6 months. Odd numbered versions will not get patches once there is a new stable.

Even numbered stable versions go into LTS 6 months after initial release. LTS support lasts like 2+ years.

Node v6 comes out this April, and Node 5 will then be discontinued. Node 6 will become LTS in the fall.

---

Stable: if you want new stuff

LTS: if you don't care about new features and want to be able to use a major version of node for years.

(Neither will have breaking changes once cut)

[Fishrock123]

(If you bind to Stable you will have to upgrade the Major (breaking) version every 6 months, but you get new features)

[D1no]

Hey, thanks @Fishrock123 for checking by. Yes, this was picked up as a means to long shot for the next LTS, targeting stable now once for April and stay with it as LTS in October (https://github.com/meteor/meteor/issues/5124#issuecomment-182459156). So targeting stable would just happen this one time. Tailing stable long term is probably a rather undesired hassle.

[tomByrer]

Upgrading to v4/v6 could be seen as a gift to the Node devs also; I'm guessing Meteor is the only platform with active development that still is stuck on the outdated Node version.

[MylesBorins]

I'm a member of the node LTS team... let me know if I can help with this at all

[faddat]

I don't know if we are taking opinions or not, but mine would be to go with stable and eat the maintenance. Keeps meteor on the edge of things.

[lukeadams]

@faddat I agree. Attempting to build with latest Node v5.8.0 leads through a tunnel of ancient dependencies. A ton of time will have to be invested to upgrade, test and ensure compatibility...
Keeping deps (relatively) recent solves this for in the long run.

[Wooobee]

I am desperate waiting for an update. This framework is so great, but how to convince my colleagues or customers if we run on an outdated node version?

[laosb]

True. Want to see MDG's decision on it. It seems that Meteor is now quite a lone distance from the edge. Whichever release of node, we just need it updated instead of struggling to figure out a "best" solution, because it just changes day to night.

[justinr1234]

Lack of latest nodejs, even with the niceness of Meteor 1.3, is a deal breaker for me and Meteor. I keep trying to figure out a way around it, I can't seem to find it. My $0.02 ... Hope meteor upgrades and we can look at using it down the road.

[jeffshaver]

would rather be on stable than lts. i feel like if we go lts, we are just going to be in the same situation that we are in now, waiting for an update to v10 (or whatever the version is by then).

[MylesBorins]

@jeffshaver that is not a good call imho (worth mentioning I'm the node LTS human)

v5 (stable) is going to be losing support in about a month as we bump to v6. v6 will be "stable" for six months and then move into LTS.

For the best "future" support and least amount of pain switching to v6 will offer the most support, but it is going to be very rocky until it hits LTS. Stable is a bit of a misnomer, since we actively merge stuff into v5 that we know will likely have edge cases. That is how we find them and fix them. So it would mean waiting until October for v6 or moving to v4 now.

¯_(ツ)_/¯

Anyways I'm likely not going to respond to this thread again as it does not seem like the Meteor team are directly responding, and I want to avoid creating noise.

[jeffshaver]

@TheAlphaNerd I understand your point for sure. I just don't want Meteor to end up in a situation again, where we are literally like 7 versions behind main node development. But I understand (I think) the dangers of going for stable over lts. And yeah. seems to be a dead thread for MDG

[rgoomar]

So, I think if the overall process for upgrading or setting a node version for Meteor improves, these kinds of issues will dissolve. I would say that they should use the latest LTS (at the time of the upgrade) if the process is still something that takes awhile. Otherwise, if the process is improved and is easy to upgrade, use the latest Stable. Maybe it can even be programmatically set by using NVM or something similar to always get the latest 5.2.x and that will keep it up-to-date with 5.2 with patch versions upgraded.

Just something to think about.

[benjamn]

So, I think if the overall process for upgrading or setting a node version for Meteor improves, these kinds of issues will dissolve.

That's exactly right. As long as we implement support for multiple Node versions instead of simply supporting one new version, it will become very easy to upgrade the default version whenever appropriate.

[SilentCicero]

@benjamn I'm saddened to say my teams are moving all our projects and packages away from Meteor as it has failed to keep the node version up to date (which we desperately need for all our web packages). We were so excited about NPM integration with 1.3. But unfortunately all our projects will eventually dump Meteor for webpack/react. We need the latest node version to run the NPM packages inside our Meteor builds. A real shame. Meteor has an awesome build environment, I loved contributing to it, but we have to move on. I thought this node version business would have been taken care of months ago.. It's our central reason for moving away from Meteor. Any word on any timeline for upgrading the node version?

[mikeifomin]

@benjamn

As long as we implement support for multiple Node versions

Any ETA?

[laosb]

So, we should figure out what prevents us going with the latest Node versions. This thread is too crowded and I think we should have a separate issue to figure it out (of course, should be a multi-version mechanism), and have a forum post for everyone to talk.

[peterkuiper]

I'm amazed that, after all these comments and people willing to step up and help, there seem to be no real answer from MDG. I read something about showstoppers, it would have been helpful if at least the known showstoppers had been listed and kept up-to-date regularly. I'm also at a point where I'm seriously considering dropping Meteor. Whatever the reason, I think it hasn't been wise to keep this one lingering for so long. This should have been higher on the priority list. Even if MDG would have been more transparant about this it could have been fixed a lot sooner with all the great people around here. Maybe I missed something here, but this is my overall impression.

@nathan-muir thanks for the great work!

[mikeifomin]

@peterkuiper all we have is some mention in Roadmap.md

[martpie]

So it looks like it's planned for 1.3.x, this should not take too long I guess

[peterkuiper]

We'll see.. I'm trying to be optimistic :)

[glasser]

Note specifically that the roadmap links to this very-active issue #6537 with lots of activity from framework team members @benjamn and @tmeasday !

[benjamn]

Today I successfully generated a dev bundle that uses /usr/local/bin/node instead of dev_bundle/bin/node, and I used it to build and run a Meteor app (with binary dependencies) under Node v5.10.1.

In other words, we now have solid evidence that the Meteor build system can process a non-trivial app using a completely different version of Node. In other other words, fibers, meteor-babel, binary npm dependencies, and a long tail of other tricky bits did not pose any immediate barriers to upgrading Node.

Here's the log:

1:~/dev% git clone https://github.com/benjamn/meteor-rebuild-test.git
Cloning into 'meteor-rebuild-test'...
remote: Counting objects: 22, done.
remote: Compressing objects: 100% (13/13), done.
remote: Total 22 (delta 2), reused 22 (delta 2), pack-reused 0
Unpacking objects: 100% (22/22), done.
Checking connectivity... done.
1:~/dev% cd meteor-rebuild-test
1:~/dev/meteor-rebuild-test% meteor npm install
-
> [email protected] install /Users/ben/dev/meteor-rebuild-test/node_modules/bcrypt
> node-gyp rebuild

  CXX(target) Release/obj.target/bcrypt_lib/src/blowfish.o
  CXX(target) Release/obj.target/bcrypt_lib/src/bcrypt.o
  CXX(target) Release/obj.target/bcrypt_lib/src/bcrypt_node.o
  SOLINK_MODULE(target) Release/bcrypt_lib.node
[email protected] node_modules/meteor-node-stubs
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected] ([email protected])
├── [email protected] ([email protected])
├── [email protected] ([email protected])
├── [email protected] ([email protected])
├── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected])
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected], [email protected])
├── [email protected] ([email protected], [email protected], [email protected])
├── [email protected] ([email protected])
└── [email protected] ([email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected])

[email protected] node_modules/bcrypt
├── [email protected]
└── [email protected]
1:~/dev/meteor-rebuild-test% meteor node --version
v5.10.1
1:~/dev/meteor-rebuild-test% meteor
=> Running Meteor from a checkout -- overrides project version (Meteor 1.3.1)
[[[[[ ~/dev/meteor-rebuild-test ]]]]]

=> Started proxy.
meteor: updating npm dependencies -- meteor-deque...
=> Started MongoDB.
babel-compiler: updating npm dependencies -- meteor-babel...
modules-runtime: updating npm dependencies -- install...
promise: updating npm dependencies -- meteor-promise...
ecmascript-runtime: updating npm dependencies -- meteor-ecmascript-runtime...
babel-runtime: updating npm dependencies -- regenerator, meteor-babel-helpers...
ddp-client: updating npm dependencies -- faye-websocket, permessage-deflate...
logging: updating npm dependencies -- cli-color...
webapp: updating npm dependencies -- connect, parseurl, send, useragent...
ddp-server: updating npm dependencies -- permessage-deflate, sockjs...
npm-mongo: updating npm dependencies -- mongodb...
mongo: updating npm dependencies -- mongodb-uri...
http: updating npm dependencies -- request...
caching-compiler: updating npm dependencies -- lru-cache, async...
minifier-js: updating npm dependencies -- uglify-js...
es5-shim: updating npm dependencies -- es5-shim...
minifier-css: updating npm dependencies -- css-parse, css-stringify...
minifyStdCSS: updating npm dependencies -- source-map...

=> Started your app.

=> App running at: http://localhost:3000/

I was also able to bundle the app using meteor build and run it using /usr/local/bin/node:

1:~/dev/meteor-rebuild-test% meteor build ../meteor-rebuild-build
xmlbuilder: updating npm dependencies -- xmlbuilder...

=> Running Meteor from a checkout -- overrides project version (Meteor 1.3.1)

1:~/dev/meteor-rebuild-test% cd ../meteor-rebuild-build
1:~/dev/meteor-rebuild-build% tar xf meteor-rebuild-test.tar.gz
1:~/dev/meteor-rebuild-build% cd bundle/programs/server
1:~/dev/meteor-rebuild-build/bundle/programs/server% meteor npm install
npm WARN package.json [email protected] No description
npm WARN package.json [email protected] No repository field.
npm WARN package.json [email protected] No README data

> [email protected] install /Users/ben/dev/meteor-rebuild-build/bundle/programs/server/node_modules/fibers
> node build.js || nodejs build.js

`darwin-x64-v8-4.6` exists; testing
Binary is fine; exiting

> [email protected] install /Users/ben/dev/meteor-rebuild-build/bundle/programs/server
> node npm-rebuild.js

> [email protected] install /Users/ben/dev/meteor-rebuild-build/bundle/programs/server/npm/node_modules/bcrypt
> node-gyp rebuild

  CXX(target) Release/obj.target/bcrypt_lib/src/blowfish.o
  CXX(target) Release/obj.target/bcrypt_lib/src/bcrypt.o
  CXX(target) Release/obj.target/bcrypt_lib/src/bcrypt_node.o
  SOLINK_MODULE(target) Release/bcrypt_lib.node
[email protected] /Users/ben/dev/meteor-rebuild-build/bundle/programs/server/npm/node_modules/bcrypt
# ... lots of additional npm rebuild output...
{ 
  "meteor-dev-bundle": "0.0.0",
  "npm": "3.8.3",
  "ares": "1.10.1-DEV",
  "http_parser": "2.6.2",
  "icu": "56.1",
  "modules": "47",
  "node": "5.10.1",
  "openssl": "1.0.2g",
  "uv": "1.8.0",
  "v8": "4.6.85.31",
  "zlib": "1.2.8"
}
[email protected] node_modules/underscore

[email protected] node_modules/semver

[email protected] node_modules/eachline
└── [email protected]

[email protected] node_modules/chalk
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected] ([email protected])
└── [email protected] ([email protected])

[email protected] node_modules/source-map-support
└── [email protected] ([email protected])

[email protected] node_modules/meteor-promise
└── [email protected] ([email protected])

[email protected] node_modules/fibers
1:~/dev/meteor-rebuild-build/bundle/programs/server% cd ../..
1:~/dev/meteor-rebuild-build/bundle% PORT=5000 ROOT_URL=http://localhost node main.js

Everything worked with Node v4.4.3 as well.

Next steps: after Meteor 1.3.2 is released tomorrow, I'll open a [WORK IN PROGRESS] pull request with the hacky changes I had to make to get this working, and we can continue this discussion on that PR.

There's a lot of work left to do, but this experiment has given me much more confidence in the basic feasibility of this upgrade.

[merlinpatt]

@benjamn How do you know 1.3.2 is going to be released tomorrow?

[benjamn]

@merlinpatt That's a fair question, but I believe I'm uniquely qualified to say that tomorrow has a better chance of being the day Meteor 1.3.2 is released than any other day :)

https://github.com/meteor/meteor/milestones/Release%201.3.2
https://github.com/meteor/meteor/releases

If you want to derail the release, I invite you to meteor update --release 1.3.2-rc.6 and find some show-stopping bugs!

[caiocutrim]

+1 for lts support

[merlinpatt]

@benjamn Now I feel dumb. I should have looked you up before asking. I'm going to crawl into a corner now.

In all seriousness, I knew that you all were moving to a faster release cycle. But I did not realize that this faster release cycle meant weekly(ish?) releases. That's super awesome because my company just did the same thing.

[praneybehl]

Really good to see this starting to happen... it would really awesome to able to get out of the V0.10.x for Meteor. 👍 👍 👍

[lukeadams]

Alright so my fork has meteor-tool working with node-stable (currently 5.10.1)
If you want to play with it, run

git clone https://github.com/lukeadams/meteor.git -b upgrade-to-node-5
cd meteor
./scripts/build-node-for-dev-bundle.sh
./scripts/generate-dev-bundle.sh

then ./meteor will run the tool! 👍
First run is slow (meteor will rebuild _all_ isopackages it needs), and installing a package is also slow first time (meteor needs to update the package versions – took a good 4-5min for me).

Does not include benjamn's commits above that allow for rebuilding of npm native modules (yet).
😄
Oh right I should mention this only runs on OSX/Linux: I don't have a windows machine with a build toolchain set up.
Some tests fail during meteor self-test and meteor test-packages (I'll post the results when I get a chance to re-run them).
One of my commits notes an issue with meteor-promise that needs to be looked into (not returning await-able promises all the time, and nested Promise awaits not working). Currently we use npm:promise, but we might want to look into using a polyfill and extending the native promise object...

[seeekr]

Quick fyi for all interested -- node v6 is scheduled for release on Tue, April 26th, with RC 3 coming out today. 6.0 will support 93% of the ES6/ES2015 standard.

[lukeadams]

@seeekr That's awesome! Looks like v5 supports ~59%, so v6 is definitely an improvement. I think we would only need to modify meteor-babel to get it to transpile by adding a preset (there isn't one for node 6 obviously)

[seeekr]

That sounds great. By the way, if you'd like some help on your branch, would you like to enable issues and post the open tasks as issues? (Or create and link a trello board or something, if you much prefer something other than GH issues.) I might be able to look into a few things as well, would be quite exciting to have Meteor running on node 5 or 6!
Re preset: I guess worst case we'd be transpiling too much until there is a preset for node 6, which would be quite acceptable -- potentially even preferable at least in some cases because performance of transpiled code might be better than native. It's actually super simple to make a preset, too, so that's not a blocker at all.

[mikeifomin]

Any realistic time/release estimation about using node 4+ in stable Meteor (1.3.5 or 1.4)
Few days, weeks?

[martpie]

@mikeifomin 3 comments ago:

Quick fyi for all interested -- node v6 is scheduled for release on Tue, April 26th, with RC 3 coming out today. 6.0 will support 93% of the ES6/ES2015 standard.

[mikeifomin]

@KeitIG node is ok, but what about Meteor?

[D1no]

I would really love to see node v6. And node is down wards compatible -
meaning - meteor can be moved from babel step by step. But integrated node
modules / processes do not have to rely on babel no more.
On Fr., 22. Apr. 2016 at 13:21, mike [email protected] wrote:

@KeitIG https://github.com/KeitIG node is ok, but what about Meteor?

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/meteor/meteor/issues/5124#issuecomment-213385036

Send from my Smartphone. Beware spelling and grammar.

Dino Scheidt
Tel.: [phone]
Luxemburger Str. 118 | 50939 Cologne | Germany
//Connect with me via LinkedIn.dino-scheidt.de

[pabloLagioia]

+1

[steveautoserve1]

+1

[lukeadams]

@seeekr Great idea! I just opened up issues on my repo.

@D1no Meteor has a bunch of ES7 features enabled in babel, so we couldn't pull it. See seekr's comment above: babel has presets that allow you to not transpile node or browser native features. (granted you are replying through email so you probably didn't see it)

@pabloLagioia and @steveautoserve1 there is a smiley face in the top right of each comment so you don't have to comment an ambiguous +1 anymore 😄

EDIT:
@seeekr looks like somebody has already created a Node6 preset 👍

[denodaeus]

@benjamn -- Now that we're up to 1.3.2.2, is that Work In Progress Node 5.X pull request coming?

Thanks for all the work -- with node 6 here, this is becoming even more important for our team to fully adopt meteor for a production stack.

[lukeadams]

Check out the PR's that Benjamn posted
v4
v5
v6

[benjamn]

Yes, note that those PRs were posted between the previous two comments!

[merlinpatt]

With 3 PRs, does that mean Meteor is getting support for each version of Node? Or is it whichever gets finished first gets support?

[laosb]

I guess, commits which apply to all node versions is pushed to repo immediately, and for now we have 3 version to choice?

[dandv]

Quick fyi for all interested -- node v6 is scheduled for release on Tue, April 26th

It happened, Node 6 is out!

[laosb]

What a long issue! Should we close this and open another one?

[livimonte]

Before closing, I think we should get a Meteor team feedback confirming the chosen version of the node to the next version of Meteor.

Roadmap

6921 - PR in progress, Upgrade to Node 4

6923 - PR in progress, Upgrade to Node 6

[seeekr]

Guys, relax. The difference between Node version 4, 5 and 6 are relatively minor, and so if Meteor can support one, it can and will support all others. Ben created PRs for every currently active and supported Node version, but the fundamental part of the work is about making Meteor work with _any_ (recent, non-legacy) Node version, and from there basically everyone should be able to freely select whichever one fits their goals and intentions best (i.e. 4.x if you don't care for bleeding edge Node, 6.x if you do; 5.x is not going to stick around for very long as it's not an LTS version).

So come and check out and help with the PRs if you're interested and you can, but if not, just rest assured this is being worked on and prioritized appropriately and I'm pretty sure Ben (and/or others working on this) will keep everyone posted on any meaningful progress.

[zeroasterisk]

http://node.green/ <-- there are certainly some serious improvements as versions evolve... but the big one is moving from 0.10 >> 4+ Anything 4+ will make me happy.

[joncursi]

jsdom (https://github.com/tmpvar/jsdom) requires Node >= 4 and this has been a requirement as far back as 4.x. Eagerly awaiting this bump.

No jsdom = no enzyme (https://github.com/airbnb/enzyme) for testing React components.

[benjamn]

jsdom might also be a (much) better solution for headless DOM testing than PhantomJS

[cesarve77]

+1

[doriansmiley]

+1

[benjamn]

The next release of Meteor (1.4) will include Node 4. Please follow the latest developments here.

[mitar]

This has been released. Meteor 1.4 and newer has node.js 4 (TLS).