Node.js 5.0 Released | Hacker News Reader

Node.js 5.0 Released

github.com

278 pointsscorchio123 comments

So there seems to be folks complaining about how fast this release was and other folks saying it's not a big deal because 4.2.x is LTS. But I don't see anyone addressing the actual issue of breaking changes in node: npm.

What does a module author do? If my module uses an API that was changed in 5.x, do I only support 4.2.x, do I only support 5.x or do I write in some hacks to try and check between the two? What if 6.x comes in, say, 6 months and also breaks another API. Now I have 3 hacks or I only support 4.2.x or 6.x.

This is the first major version since the io.js and node.js merger so I'm not that concerned yet but if they continue this pace then I will be very concerned (just like I was concerned when npm was supporting io.js and node.js when they had differences in their APIs; it forces module developers to choose and limit their availability). I would like to see some path of deprecation for node.js APIs that take multiple major versions to get away from unless it's a major security risk.

Edit: just to clarify my worry: I'm not worried yet. But, and this is a big but, ECMAScript doesn't include any standard libraries for interacting with systems, http, etc so node.js has kinda assumed the role of a standard, defacto library for JavaScript when dealing with a system on a level outside of a web browser. So if the breaking API changes are going to occur every year or faster, to me that's like a language's standard libraries changing every year or sooner.

Yes it's kinda not fair as node.js is NOT a set of standard JavaScript libraries but that's the role it's essentially been given due to the lack of one in ECMAScript.

ISTM one could keep developing for the old nodejs under the current major version, or even the current major version plus a few more major versions. Then simultaneously release under a different major version for the new nodejs. The "engines" option of package.json makes it possible to partition one's releases this way.

This may end up deviating a bit from semver, but node and npm have long done that themselves. Ideally, of course, one could simply avoid using unstable portions of the API. That's not always possible, but it should be possible to isolate that instability in a module like "readable-stream". Actually I suspect that any time one is tempted to use the "engines" option, it's time to break that specific API use out into a separate module.

Does "engines" actually make it possible to partition your releases? I thought by default the engines part of packages.json was ignored.

Whoops, you're right. I guess there must be good reasons for that default. Maybe there has to be some version-checking in the API-using code itself. That makes it an even better idea to isolate that shit in a separate module.

How is this different form any other package tool?

PIP authors have python2/3, Julia pkg, ubuntu apt-get, ect. What's special about working with npm?

Python community doesn't release new versions nearly as fast. Every major python version release, there is usually a PEP announcing the schedule new version release date far in advance for the community to prepare.

To me, Node community just release new versions fast and furious. If the committers won't, then there are people who jump out and fork the project.

Of course there are the other extreme of long release cycles like Debian but there are good reasons for that.

IMMO, a mature large community of an open source project community should always take the package ecosystem into considering when introducing new versions or breaking changes.

PS: I was pretty annoyed that one of the npm package I used a lot `aglio` is broken again on 5.0.0 after I filed a ticket for the compatibly issue with 4.2.1. This ticket has just been closed a few days ago and is only less than two weeks old!

https://github.com/danielgtaylor/aglio/issues/183

So like my comment said I'm not that concerned about it today but if they are going to make breaking changes every 6 months then I'm worried and for two reasons that kinda separate node / npm apart from other packaging systems.

First, JavaScript lacks a standard library that can interact with a system so node.js is essentially the defacto extension of the JavaScript language to work with a system. If you had a change where its standard libraries change every 6 months (plus or minus a few) it wouldn't be fun.

Second, npm supports specifying the engine but you need to be able to update all versions due to security concerns, etc. If it's iterating too quickly with breaking changes then people are going to have to keep a branch for every version and update each one when a security fix is required. That's not sustainable. Most people keep a LTS version and a bleeding edge version.

Python and other languages iterate but breaking changes in core APIs? Not very frequently.

hey! do you have a specific problem in mind or is this just a hypothetical musing?

'cause the actual changes that break between npm 1 and 2 are very small. (the changes to npm run, mostly, and the cache.) so it's Very Strange(tm) modules that break, and the new run behavior is much more useful

- npm team member

Like I mentioned in my comment I'm not worried yet but if the node team iterates at this pace with breaking changes than I worry as node is essentially the defacto standard library for JavaScript when interacting with a system (since the real EMCAScript standard lacks interacting with file systems, http, etc). How many languages do you know that have standard libraries that iterate breaking changes frequently? Probably almost none that are mainstream.

It's not really anything against npm itself and if the node team doesn't do this with high frequency then it won't be an issue. The 5.x coming so soon after 4.x was just jarring and everyone is speculating how frequently they're going to make breaking changes.

Is there / could there be an option in package.json for which Node version you support? Like, v1.0.0 of my lib supports up to and including Node 4.2.1, but v2.0.0 requires Node 5? That way people would get a working version relatively seamlessly.

I realise this makes the package.json Node-specific, which might be something you want to avoid.

EDIT: to part-answer my own question, package.json has the "engines" field. Not sure if that means it automatically installs old versions in older versions of Node, though.

This is still current as far as I know: http://www.marcusoft.net/2015/03/packagejson-and-engines-and...

Basically, you get an error but it won't give you the proper version. If that has changed I'd love to know, however (it most certainly should install the latest version for your environment and give you a warning that it's not the latest. In my opinion anyway).

By "npm" I assume the author meant "packages in npm", not npm itself.

Right, but packages _in_ npm are still managed by npm. If it were to change the package format between major versions, there could be problems. At least, that's how I read the OP.

I read it as: how do authors publishing packages on npm maintain compatibility between multiple versions of node with breaking standard library changes?

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.

A bit more conservative version numbering would be great. Nodejs up to 0.1x was to slow, and now it's way to fast - a application runtime is not a browser. Mind the library compatibility - not every dev has time to test for 0.1x, 4.x and now 5.

Yes, it's important to conserve integers lest we run out

He's talking about the speed of code-breaking changes... and now a fragmented install base (similar to the Android problem).

There are still major libraries that haven't updated their engine requirements in package.json to reflect that "proper" Node.js is now above 4.x (versus 0.10.x or 0.12.x), for example. It is a little bit surprising to me that they are at 5.x already.

You know, it's pretty funny that all the io.js people (myself included) were complaining about how glacial the pace was from Joyent, and now here we are, seeing some grumbling about how quick the pace has picked up. :)

For Node.js core APIs, there is a deprecation strategy that requires at least one major version cycle before anything can be removed, and even then the chances of things actually being removed are slim. We're trying to take a very cautious and conservative approach to breaking changes in core. Generally, if it works in v4, it should continue to work in v5, if it doesn't, that's a bug that should be reported and fixed.

Changes in npm, on the other hand are a different story. Technically, npm is not part of Node core, it's a utility that we bundle with the core but it has it's own lifecycle, it's own process and it's own separate project. The "contract" between npm and node.js is still being worked out and this kind of feedback is extremely useful.

> For Node.js core APIs, there is a deprecation strategy that requires at least one major version cycle before anything can be removed

Considering there was 52 days between one major version cycle that criteria isn't really useful; I'd expect a timeframe more than a version cycle.

> Changes in npm, on the other hand are a different story. Technically, npm is not part of Node core, it's a utility that we bundle with the core but it has it's own lifecycle, it's own process and it's own separate project. The "contract" between npm and node.js is still being worked out and this kind of feedback is extremely useful.

I really should have said the main issue is really just writing code with node and sharing it; node has essentially been given the responsibility of being a standard set of libraries for JavaScript on the server and having standard libraries change APIs, even minor, in less than 2 months is typically indicative of a language pre 1.0.

But I'm hopeful you're right and things should continue working in most respects, it's just the edge cases that worry me. I don't want to spend a ton of time developing something that ends up simply not working in the very next version without a good path of providing my code that works with both.

To be clear, v4.2 is the stable dependable target that most users should be using as their target. Developers that want to track new development and new features and have more flexibility can move up to v5. Next year at around this time, v6 will become the new stable target. The actual number of breaking changes between v4 and v6 are likely to be quite small -- things that work in v4 should continue to work in v6 and beyond really. So the best advice I can give is: if you are developing modules for developers to use in their applications, you'll want to primarily target v4 for now but keep an eye on where v5 is going and use that as your beta channel for new development going forward.

Good lord people...

1. There is no one forcing you to upgrade, 4.2 is LTS, you've got 2yrs+

2. 5.0 followed 4.0 so closely because 4.0 was the iojs/node merge and 5.0 was to correspond with the new V8 release, future major bumps will be closer to 6mo (to match V8)

The LTS plan: https://github.com/nodejs/LTS

'Good lord' is a bit strong. Chicken little isn't needed, I agree, but the concern is real.

In a real application, using ecosystem packages, it is fine to decide on a fixed target. But, if the core system is moving quickly, chances are the better packages will be moving quickly too. The fear is that there'll be a necessary change in a package (a security issue, or a bug that only surfaces under rare situations, for example), which can cause a cascading upgrade to the whole app. One that needs to be performed quickly.

This has happened to me once, and it wasn't pretty.

It is a concern for any platform, of course, but fast moving ones do 'feel' like they increase the risk. It's therefore a valid question to ask if there are people deploying code in long-term projects, and what the burden is in practice. Since we don't have empirical data (that I know about).

A lot of the Node community does seem to be made up of people creating apps, and enjoying the latest and greatest functionality. There is fewer information from folks running apps long term in mission critical scenarios. That's not a criticism, at all, just an observation: if you are in the latter camp, or considering whether to be, getting good information is harder.

Technical debt, in terms of platform choice, is important.

>1. There is no one forcing you to upgrade, 4.2 is LTS, you've got 2yrs+

And in 2 years, when we take a peak we see that the changes amassed in between by the non LTS releases are so big we have to pretty much rewrite all of our codebase if we want to continue getting support....

i have an app that was written for 0.8 three years ago. it is running on 4.2 with no modification. (it doesn't use any binary add ons). javascript is almost entirely backwards compatible because they can't break the web.

Other apps that require binary add ons required me to install the latest versions from NPM -- one one of them required ANY changes to how the API was called and it was extremely minor.

Waiting 2 years to upgrade the engine your code is running on is not horrible and requires much less pain

this is such a good point. I was running on the same version, then I upgraded to 0.10, 0.11, and finally 0.12 and run test on ioJS. There were no major changes to be made.

I think I'll just add Node 5.0 to CI and see if it passes and that's all there is to it really.

Yeah, but the pain comes from: binary packages, and even pure-js projects that move fast and break things -- you can easily end up with 50 or 200 dependencies for a large node project (not merely some micro-service), especially as packages depend on each other with wild abandon even for trivial stuff they could have wrote themselves.

This is the fundamental problem. As an engineer you have to weigh every single dependency as a cost. If you take a dependency on 200 packages, then NOTHING is going to save you long term as things break.

More or Less, Joyent was mostly doing what they were doing for a reason. What the io.js team is doing also has validity but fundamentally you will always see these issues to some extent because of the philosophy behind it.

If you are at 5.x today, and 6.x sometime next year, as a library author why would you - next year - decide to write a package for something for 4.x? That is 2 major versions outdated. If it's really major bumps every 6 months and 7.x comes out next year too, who's going to be writing new stuff for 4.x? Most new packages will probably support the current version, and then your LTS window of 2 years doesnt mean much.

> If you are at 5.x today, and 6.x sometime next year, as a library author why would you - next year - decide to write a package for something for 4.x?

Because the target user community of what you are writing consists of the kind of users that are likely to use LTS releases.

> Most new packages will probably support the current version, and then your LTS window of 2 years doesnt mean much.

You don't choose LTS because you want support for every new packages that haven't been written yet on the day they come out, you choose LTS because you've got something for which you want to have a stable platform with bug fixes, rather than an unstable platform with breaking changes, and are willing to not have access to the newest platform features or the newest third-party libraries that depend on them to get that stability.

If by "match V8" you mean "skip most V8 changes"? V8 revs on par with Chrome, at a pace about four times what you say.

Turns out that despite pillorying Joyent for sticking to V8 major versions, it is the only reasonably-correct thing to do for the ecosystem to remain usable.

"V8 Major versions"

io.js made a lot of noise about this, and has reached a "compromise" position that is indistinguishable to the end-user - or is LTS going to take V8 version bump over its 2.5-year life?

No?

Then take your scare quotes and bang your drum elsewhere, because from where I stand, the new boss is pretty much the same as the old boss.

I recently looked at using Node for a simple API backend. ES6 seems like it's not there yet, the stability of Node makes me wary. Constant changes seem exhausting to keep up with. For a simple microservice api you don't want to be upgrading it every 3 days. The continuous change doesn't make sense to me. Trying to get up to speed on all the Node.js ecosystem feels exhausting, only to have it change a few weeks later. Maybe someone using this daily for real APIs could comment if this is the case for them?

I ended up opting for Flask and Python 3x instead, couldn't be happier. I had my API up and running within a day with no prior knowledge of Flask and some Python on and off. I've been able to discuss and teach other team members on it who were also able to pick it up easily.

No need to always be on the latest version. v4.2 is an LTS branch that will be supported for the next two and a half years.

And with tools like nvm, it's incredibly easy to swap out different versions and go for a test drive.

"n" is another good node version manager that makes switching versions painless. https://github.com/tj/n

Node.js keeps in line pretty heavily with V8, so if you're keeping up with changes in Chrome's JavaScript engine, you're already keeping up with Node.

Plus you don't have to always upgrade to latest and greatest. If your app works fine in 4.2 and there's no crazy security issues you need to upgrade for, don't. 4.2 is LTS so it's going to get supported for a long time.

There is continuous change, but the changes tend to be quite small. You can also safely stay on older versions for a long time (4.2 is LTS).

You could've used Node 4.2 LTS and a simple Express server (is Flask the Express of Python?) and had as much stability. That said, I do understand your skepticism and concern.

I'd say bottle if you'd want to go for simple and small. Flask has two huge dependencies, one of which is template engine which you wouldn't need for a simple API.

JS in general moves fast and packages range from great to WTF in quality. I would suggest using Babel(or something similar) for all future JS development. That way you can use ES2015/2016 features now and have them work in most environments.

I have a built a small API using express and passport and so far these node changes have not impacted my code.

Another option for fast API development is Java 8 with SpringBoot and Jetty. People hate on Java and Spring, but the latest versions of both are very powerful and easy to get going. If you end up needing more it is there.

But then you have to keep up with Babel changes too... http://babeljs.io/blog/2015/10/29/6.0.0/

Why this urge to keep up to the latest and greatest? Especially for a transpiler? If it is converting your code just fine, why update?

Probably the concern that waiting between updates means that if you are forced to update for some reason (critical bug or must-have feature) you have a tougher upgrade path.

Because if you don't, then a year or two down the road you're left with an unsupported legacy hell.

Node.js modules: from brand new to "unsupported legacy hell" in "a year or two."

There's no way this is sustainable, but I'm at a loss of how to fix it, especially when the ECMAScript language itself is evolving at such a rapid pace. Any ideas?

There were 6 years between ES 5 and 6, and it will most likely be another 1-2 years before we have complete, well tested ES6 coverage across all major browsers. ES6 is fully backwards-compatible with ES5 anyway, so it's not even a Python-kind of language evolution.

It's a cultural thing.

JS being relatively fashionable and easy to write, it attracts all the younger devs that can't be bothered with backwards compatibility, stability, etc, and keep changing, restructuring etc their projects as they go along.

There are exceptions of course, e.g. anything by jashkenas, but this breakage happens a lot. Also with people adopting the latest shiny new framework every year or so (e.g. it feels like ages when Backbone was the shiny new thing, but it was merely 5 years ago -- since then we've had Ember, then Angular, then React take the spotlight).

Rapid pace is fine because the language spec is backward compatible. The module problem is rather mostly on the API level. To fix:

• On the technical side, needs the equivalent of CPAN testers to automatically show where stuff breaks.

• On the social side, needs the fostering of a culture where breakage is considered ill-mannered, and module maintainers hence go to lengths to prevent it or fix it promptly.

>but I'm at a loss of how to fix it, especially when the >ECMAScript language itself is evolving at such a rapid pace. >Any ideas?

Avoid Javascript on the server, problem fixed.

Pretty much. It's not like we're stuck for options.

I would agree and why I brought up java 8 and SpringBoot above.

In the case of Babel - performance. Even with all the fantastic work that has been done on it so far, good luck avoiding massive transpile times for non-trivial ES6 code bases. I imagine TypeScripts (and other) transpilers have the same issue.

In a project with over 600 required js files, 25kloc in project, way, way more from npm: the whole compile takes around 25s.

An incremental compile takes ~1-2s.

Babel does some other magic that you might not realize, such as converting anonymous functions to named functions (and then assigning those to a variable of the same name).

It has some magic, but we already have to use polyfills to support multiple browser versions. I see something like Babel as the global polyfill of the future. Use latest es features now and have them go native over time.

javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.

You jest, but this week i've been developing my first java web app using play framework, coming from a decade of PHP and javascript, and i found the experience surprisingly nice. You can get a good edit-refresh cycle going using incremental recompilation, and the api's are elegant and flexible. My preconceived notions of the verbosity and ugliness of java web app code proved unfounded.

Java was heavy, and still is but most of the perceived weight came from immaturity (the world wanted freeform template oriented scripts). Now all languages are moving towards types, packages/modules, conventions and structures. If a php3 dev discovers php 5.6 I'm sure he wouldn't enjoy it.

> I ended up opting for Flask and Python 3x instead

Yap good choice. Python to me is more readable (so I can understand my own code and others' better) and I find the echo system to be friendlier and more mature.

Funny how yesterday in the pypy thread it was all doom and gloom for python and yet in the real world people keep choosing it for new projects.

It's almost like there are many people doing many things in many directions all at once!

Why was the pypy thread "not the real world" when this thread "is the real world"?

We have apps on Node v0.10, which is over 2.5 years old and will be supported for one more year.

3.5 years for an API, that's decently long, but dependent on industry. What does your upgrade path look like? Are you basically rewriting everything into ES6, aka starting over? Three years isn't long in a corporate environment.

We've lightly tested some of our components, and they work unchanged in Node 4. Heavier testing may find a couple of issues. The only reason we haven't switched is that need for heavier testing. No big rewrite will be needed.

Good to know, thanks for responding back.

As an engineer, I assume you use a programming language and the libraries from its ecosystem to solve problems. Unless the latest features are essential to solving your problems, I would say this is unnecessary worry.

We use both ES5 and ES6 (via transpilation) where I work. I had to write a lot of the tooling to support ES6 because a lot of front-end engineers were asking for ES6. To this day, I have yet to hear one engineer justify their "need" for ES6 with one of the features that make something easy that is hard or cumbersome with ES5. Pretty much every feature engineers were wanting to use were simple sugary syntax features like the spread operator that is trivially dealt with with a library like `xtend` (the irony is seeing these same engineers continue to use _.each on arrays instead of Array.prototype.forEach)

There is a corollary to Wadler's Law in here somewhere: https://wiki.haskell.org/Wadler's_Law

    In any debate on the merits of migrating to ES6, the 
    total number of times an ES6 feature is cited as 
    justification to migrate to ES6 is proportional to two
    raised to the power of its position.
           0. Semantic features
           1. Syntax features
           2. Lexical syntax features
           3. Lexical syntax of comments features

There's a lot of confusion and concern in here about the release of a new major version very soon after the release of another major version (v4.0.0 was released just a month and a half ago). Please note that this is a special release prompted largely by the odd timing of a new release of Google's V8 [1].

If you're looking for solid, long term stability, you are perfectly fine sticking with v4.0.0, as its marked an "LTS" release. This means it'll be actively receiving minor- and patch-level updates for 18 months, then for 12 months thereafter it'll get updates for severe bugs and security problems (what they call "maintenance" mode) [2].

[1] https://twitter.com/rvagg/status/659871982670884864 [2] https://medium.com/@nodesource/essential-steps-long-term-sup...

Re: From the linked Twitter: "Don't feed the trolls."

I personally don't have an opinion on the quick release and am happy to just use the LTS but calling the developers "trolls" seems unnecessarily harsh for people voicing a reasonable concern, even if they were just misinformed.

I'm not sure why so many people are freaking out.

Looking at the changelog, it looks like they decided to commit a bunch of breaking changes that were previously marked as deprecated. If your code was running before without warnings, upgrading shouldn't have a negative impact.

The pace of change is fast because node ES6 support is progressing fast enough to maintain near 1:1 feature parity with v8. A bunch of ES6 features still haven't been fully implemented in v8 but that's not the fault of the Node.js dev team.

If the dev team has committed to LTS for 4.2 that means they're likely planning to backport new features to the 4x branch. No reason to panic. Many of the more useful features of ES6 already work perfectly in 4.2.

Probably because their sole research into this issue was seeing that a number went from 4 to 5.

> I'm not sure why so many people are freaking out.

Probably because you don't use any binary packages that haven't even made it to 4.x yet. My app requires one so I'm still stuck on node 0.12 until they update. I've filed a bug report but before they could even respond 5.0 is out. Not they have a quandary: do they support 4.x or 5.x when they update? Npm doesn't support forks, so they can't get one version for users of 4.x and one for 5.x.

The only sensible way to fix this that I can think of is to build in an extension layer into node so that binary packages don't use raw v8 APIs (since those seem to change a lot). Then that layer can be made (more) stable, even in the face of constant v8 upgrading.

>The only sensible way to fix this that I can think of is to build in an extension layer into node so that binary packages don't use raw v8 APIs (since those seem to change a lot). Then that layer can be made (more) stable, even in the face of constant v8 upgrading.

That already exists, it's called nan: https://github.com/nodejs/nan

Yes, but it should probably be made to be the only way to make extensions, instead of being optional.

Glad to see they've bumped up the V8 version so the spread operator can be used.

Things are really moving along at a good clip since the merge with io.js.

Yes, I'm very excited about the spread operator! I've been spoiled by Firefox.

Looking at documentation.. does this only work on lists (or list like object)? I.e. you can't "expand" a k:w object? Or is there another operator for this? Example:

    function foo(a=1, b=2, c=3) { return a * b * c;}
    dict = {'b': 4, 'c': 6};
    foo(...dict);

Yes and no.

You can still do something like:

    foo(... Object.keys(dict).map(name => dict[name]))

(Maybe someday you might be able to use Object.values() to achieve the exact same thing without needing to use .map)

However, the spread operator doesn't match the argument names to the object names. So the above call would mean the following:

    foo(4, 6)

And not what you'd like:

    foo(undefined, 4, 6)

However, note that you can rest an object too:

    let x = { a : 1, b : 2, c : 3 };
    let { a, ... rest } = x;

    console.log( ... rest ); // { b : 2, c : 3 }

There is a proposal for this but I'm not sure what stage that's in

Stage 2

https://github.com/tc39/ecma262 https://github.com/sebmarkbage/ecmascript-rest-spread

Technically, the spread operator works with iterables [1]. If you wanted to spread an object `obj`you'd need to define `obj[Symbol.iterator]` [2].

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

You still have to simulate named arguments with an object:

    const foo = ({ a = 2, b = 2, c = 3 } = {}) => a * b * c;
    const dict = {b: 4, c: 6};

    foo(); // 12
    foo(dict); // 48

We use node on Windows for our asset minifiers, hopefully the new version of NPM will make this a little more pleasant!

Your dependencies will now be installed maximally flat. Insofar as is possible, all of your dependencies, and their dependencies, and THEIR dependencies will be installed in your project's node_modules folder with no nesting. You'll only see modules nested underneath one another when two (or more) modules have conflicting dependencies.

I can testify that this is a Big Deal. I manually upgraded to NPM 3 for my own minification/bundling system because the old behavior was breaking dependencies (one package passing React objects to another, and each one depending on different versions of React). Part of the issue is that the old method of dependency resolution, especially for peerDependencies, was just awful.

Maybe Microsoft wakes up to fix the MAXPATH limit (260 chars). Recently the improved UI of the environment variable dialog, after 25 years.

Many (most? all?) windows apis that take absolute paths can take extended length paths. Extended length paths (just add \\?\ to the front of your normal local path, or \\?\UNC to the front of your UNC paths) allow up to 32K paths.

I'm not really sure why node doesn't use them internally to solve the issue.

Only a few WinAPI functions can take UNC path, Explorer and cmd.exe don't support them either. The same problem has with the dotNet framework which is implemented on top of WinAPI.

Nodejs is a console application and can call system applications via command line/cmd.exe.

WinNT kernel and NTFS/ReFS have no such path limitations, that limitation comes from Win16 API and to make the job easier the Win32API and its subsystem (32-bit and 64-bit Windows since Win3.11 with Win32s addon and Win95) comes with such legacy restrictions.

You can use npm@3 without upgrading node - we use npm@3 and node 0.10 at work, although we mainly use it for out build tools and haven't migrated out node microservices - yet.

And it still uses OpenSSL as a CSPRNG, rather than the operating system's CSPRNG (CryptGenRandom, /dev/urandom, etc.). I guess maybe they'll fix that in 6?

And use what in Windows? A closed-source CSPRNG? Has there ever been a serious vulnerability/problem found with OpenSSL's CSPRNG? I'm actually curious as to why this is an issue.

Only the OS can guarantee that some entropy is not handed out twice. If you can't trust your OS with that, you might have bigger problems.

This release timeframe was announced quite a while ago. As others have mentioned the quick jump from 4 to 5 was primarily due to the io.js convergence.

Expect future major releases on a 6 month cadence with LTS releases every 12 months

https://nodesource.com/blog/essential-steps-long-term-suppor...

For a person who's not well versed with Node's version history, what's in this update to warrant a jump from version 4 to 5?

Node now follows Semver. If you look through the changelog, there's more than a dozen changes that are breaking.

That doesn't answer the question. Node 4.0 was released a month ago. Why are there so many breaking changes in 1 month?

From what I understand the 4.0.0 release was to merge NodeJS and io.js into one stable product as soon as possible. 5.0.0 now goes further in integrating features that were not ready to release at that time. Further major version updates are to be less frequent.

Mainly the upgrade of V8. The release of v5 so soon after v4 is a special scenario prompted by the odd timing of the release of the new V8. It's worth noting that v5 is not an "LTS" release (that is, it won't have the same long-term support that v4 does). I believe even number releases are LTS releases.

Thats not the question that was asked, yours is a different question. The main reason is because they are tracking v8 versions. This one hits v8 4.6 - v8 is released every 6 months and we will see node v6 in April.

Really what has happened is that v4 was a bit behind, and v5 is right on schedule which is why it seems to be changing so fast.

> Why are there so many breaking changes in 1 month?

Because that's when the planned functionality was coded, tested, and ready to deliver.

Node's development model is a form of the fairly common model where you avoid wasted work (that is, work not delivering value for customers that want it) by delivering features as soon as they are ready and tested, while periodically splitting off and committing to support long-term-support releases for customers that are more concerned with longer-term stability than having the latest and greatest the moment its ready to use.

@Touche: because they were introduced by the developers. The type of changes you make dictate the semver, but semver doesn't dictate what changes you can or can't make.

AFAICT there are quite a few changes that are technically breaking changes, but most projects won't be affected. The one big change that I see is mostly hidden: the change from NPM 2 to NPM 3. Make sure you check out the changelog for NPM3: https://github.com/npm/npm/blob/master/CHANGELOG.md#v300-201...

I believe they updated the version of v8 they're dependent on, which causes them to bump the major version too.

Typically, with standard breaking changes they just bump the minor version but with v8 updates or with major api changes they will bump the major version.

4.0 being LTS pretty much requires early 5.0 release. While side-effects are significant, this is the only way to have both LTS and momentum.

Uhh, wait, wasn't nodejs 4.0 only like a month ago? So are there going to be breaking changes every few months now?

Sort of, yeah. They're taking a very strict approach to semver - if it could potentially break anyone's code out there, it's a breaking change that warrants a major version bump.

I'd wager that the vast majority of Node APIs currently on 4.x could swap in 5.0 without any issues.

Yeah, why not? Just because they upgrade node, doesn't mean you have to use that version. If you want a stable version, you'll be on the LTS release that will be supported for a long while

The only problem with that is npm is used across all versions. So each version of node that has breaking changes, what do you do as a module author? You might have to drop support for one version or the other or you add in some hacks to try and figure out which APIs you can and cannot use.

Moving fast is one thing and this is the first major version after the io.js and node.js merger so maybe this is a one-off thing; if they continue this pace with breaking changes then the ecosystem is either going to only be latest or are going to stick with 4.2.x forever.

> You might have to drop support for one version or the other or you add in some hacks to try and figure out which APIs you can and cannot use.

If this happens, there will probably be compatibility modules like https://github.com/nodejs/readable-stream.

Use the LTS version.

My current node version is 4.1.0 and npm is 2.14.3. I don't see any reason to upgrade. Node PLEASE implement HTTP 2.0

Upgrading to 4.2.x will give you LTS.

This release supports ALPN, which is what was needed to get this to work: https://github.com/molnarg/node-http2. In short, HTTP 2.0 support in this release _is_ your reason to upgrade.

seems to be broken for mac os x, installed from 4.0.0 and seems that npm is broken, running npm install gives me npm ERR! code MODULE_NOT_FOUND.

i reverted back to 4.0.0

Yeah, habemus spread operator! I also hope v6 Will be full ES6. Right now classes can be user only in strict mode :(

Spread operator, yay!

Support for in-process multithreading already?

I found this out last night at 3am after rushing to provision a server. i don't have a great handle on semver or dev cycles, point ceded, but they released 4.2 on october 12th. thats like .1 every 2 days.

The major version number change doesn't mean a ton of work was done, just that there were breaking changes.

Semver versions aren't decimal numbers, the dot is a separator between categories with different semantics, not a break between tenths and integers.

Even non-semver version numbers are rarely decimal numbers, even though the major/minor distinction may be less clearly defined.

So talking about a 0.1 every n days inferred from the date of a 5.0 vs. A 4.2 release doesn't make any sense; if there were actual minor releases that frequently, it would, but that is a different thing.

People have to lose this idea that the version numbers indicates time. It doesn't.

(for semver at least)

Reply on news.ycombinator.com