There are jessie iojs packages from nodesource:

• https://deb.nodesource.com/iojs_1.x/pool/main/i/iojs/
• repo key: https://deb.nodesource.com/gpgkey/nodesource.gpg.key

sources.list lines for jessie:

deb https://deb.nodesource.com/iojs_1.x jessie main
deb-src https://deb.nodesource.com/iojs_1.x jessie main

They are based on Chris Lea's Ubuntu packages, which we have used for 0.10 testing in the past. This means that they differ from Debian 0.10 packages by not building a separate npm package.

I think it's worth considering the upgrade for our Jessie installs. That would avoid affecting any older services including Parsoid or those on the sca cluster.

I would strongly recommend against Wikimedia adopting io.js at this time.

To think it'll just be a performance boost with happy ending is naïve. There will be additional maintenance overhead and inherent stability/upkeep cost. I don't believe we have resources to worry about that.

The project more or less started as a dare because Joyent wasn't maintaining Node.js well. However, many people involved with io.js are also involved with Node.js. It's unclear to me whether they were blocked by Joyent or just principally unwilling to continue. It relates to their demand for an open governance model. After no satisfactory response to that demand, part of the community forked and created io.js. The project is immature at this point. (Started a few months ago, in January 2015.) It seems irresponsible to run in production.

Since then, a lot happened. There's an enormous amount of discussion and restructuring going on. Here's a summary of just one week of activity (April 3rd in this case): https://medium.com/node-js-javascript/io-js-week-of-april-3rd-a4e1fe0c38c1#d576

• Help us reconcile node.js and io.js, Mikeal Rogers (io.js Project Team)
• joyent/nodejs-advisory-board: Project Lifecyce with io.js WGs, Proposal was merged by Bert Belder (Node.js Advisory Board)
• io.is: Request for comment "thoughts on reconciliation", 205 comments since last week.

It has no corporate backing at this point (does this matter?). They're still figuring out whether to join the newly created Node.js Foundation, or to start their own foundation etc.

It's also worth thinking about the signal we'd be sending to the world. Wikimedia Foundation has a voice. Do we want it to speak encouragement of io.is? Or should we stick to boring Node.js and give them time to figure it out first? Personally I expect them to reconcile. Because, unlike the Blink/WebKit fork, there are no major technical disagreements on what the software platform should look like.

Also note that Node.js has received several releases since January 2015 and the repository seems to be picking up pace slowly. Including pull requests from io.js. And many of the same people involved with io.js contributing to Node.js still.

Excuse my brevity, but please know that I neither oppose nor support io.js, I don't know enough about the situation around its governance model at this point. It seems io.js made some good points. But my argument is not based in that.

@Krinkle, you seem to be more concerned about naming & the political situation. I don't think that those aspects matter that much. Node 0.12 and iojs remain broadly compatible. In fact, we have been testing each commit against both for a while now. Your assertion that node 0.12 is more stable or reliable requires a citation. We have not seen such a difference in practice.

I think it is also safe to say that we can use whichever project emerges victorious next without significant trouble, be that node 0.14 or iojs. We'll continue testing all our projects against both. Lets make our decision on technical grounds, without worrying too much about politics or FUD.

At the technical level, iojs does have more mature support of ES6 features:

• only exposes stable ES6 features by default, compared to node 0.12 exposing all of them (incl. unfinished ones) with --harmony
• uses a more mature & supported version of v8

It is thus a better option for carefully adopting stable ES6 features. This lets us reduce our reliance on ES6 shims, which is good for reliability and performance. We are widely using ES6 collections, Promises, Object.assign and others, all implemented in shims.

Will Node.js continue to be supported for non-WMF installations?

@tstarling: Generally yes, for reasonably recent versions. RESTBase is supporting & running CI against Node.js 0.10, 0.12 and iojs. Parsoid is still supporting 0.8 as well, but is just deprecating that.

For the most part, shims will keep things working on older node versions, at the cost of performance. For some projects we might elect to use generators, which are only natively supported in Node 0.12 with --harmony parameter and iojs. However, we could still make those work on 0.10 and probably even 0.8 using the babeljs transpiler.

@GWicke Experimental or non-default flags like --harmony are not practical requirements for stable release of our software; such flags are not supported by the package.json engine specification. I would recommend making sure that RESTBase and Parsoid work properly under Node 0.12 from a regular npm dependency.

Similar to what CoffeeScript packages do. That means any ES6 syntax not supported by Node 0.12 by default would have to be compiled by Parsoid (not the customer) using an npm preinstall or prepublish hook.

Note that coffeescript packages are typically not handled "properly" by npm, either -- they depend on require('coffeescript') being included first, which then "teaches" npm how to load .coffee files. Packages which require --harmony or babeljs support would be analogous.

I think you are dismissing --harmony inappropriately. It is not an experimental flag. It's more akin to, say, using python3 instead of python2. The shbang at the top of the file tells you which version of the language to use. Nobody uses npm's "engine" flag in package.json; requiring that to have some syntax for --harmony is inappropriate.

It should also be noted that io.js is a "friendly fork" of node.js, with the expectation that they will resync in the future. And they are both chasing v8, which is chasing the ES6 language spec (just made final this month). So it's not like we're actually going to get multiple language variants here: everyone's running toward the same point, it's just that io.js is getting there a bit more quickly these days.

iojs is about to release v2.0.0. So that might be a good target for a "stable" version to install on the WMF machines. On the other hand, the recent v1.8.1 release is not expected to differ that much from v2.0.0. See https://github.com/iojs/io.js/issues/1436 for some inside-baseball release-planning details.

Today iojs joined the node foundation, and it sounds like the iojs branch will be the basis for ongoing node.js development: "The new "converged" node project will begin with io.js master and port changes from node.js in for its first release target."

• https://github.com/iojs/io.js/issues/1664#issuecomment-101828384
• https://docs.google.com/document/d/15Y_kJlYm-8cIf-alniaqUWMM-TjGISCqLf40G3pv4sM/edit

So, current iojs 2.0 will be followed by iojs/node 3.0.

Debian packages (incl. jessie) at

https://deb.nodesource.com/iojs_2.x/pool/main/i/iojs/

On IRC, @MoritzMuehlenhoff proposed to wait until LTS comes out in October.

We could do that, but it would be nice to start gradually migrating to modern v8 sooner. We know that several of our services (including Parsoid and RESTBase) are compatible with modern v8, and perform better with it. We have been testing each restbase commit against iojs in the last six months, without running into issues.

Right now the iojs debs are still named 'iojs', which makes it fairly easy to install them instead of nodejs on specific hosts, and thus gradually migrate one service at a time. Once iojs / node 3 LTS is out, we'll probably have to do some manual package tweaking to avoid replacing node 0.10 everywhere at once.

There doesn't seem to be any activity wrt packaging io.js in Debian (and the already existing nodejs is already poorly maintained). As much as I dislike using external, vendor-provided debs/apt sources, in this case we're better off with the packages from nodesource.

@MoritzMuehlenhoff, what would it take to import those packages?

I'd really love to be finally able to use those performance improvements in HTTP parsing I contributed upstream over a year ago. The new v8 version should speed up CPU-intense services like Parsoid on the order of 15%. That's over a second on large pages like [[Barack Obama]].

We can surely add them for now so that you can experiment/test with it, I can do that this week.

In T91855#1484033, @MoritzMuehlenhoff wrote:

We can surely add them for now so that you can experiment/test with it, I can do that this week.

I have imported 1.8.4 for jessie-wikimedia (iojs and iojs-dbg)

Note that these are not co-installable with nodejs from jessie (the iojs packages declare a Conflicts: with nodejs).

I have imported 1.8.4 for jessie-wikimedia (iojs and iojs-dbg)

Ohh, thank you!

Small nit: The current stable version is 2.5.0:

https://deb.nodesource.com/iojs_2.x/pool/main/i/iojs/

It would be great if we could go straight to that version.

I have imported 2.5.0 for jessie-wikimedia (iojs and iojs-dbg)