
Node.js 5.0 Released - scorchio
https://github.com/nodejs/node/blob/v5.0.0/CHANGELOG.md
======
BinaryIdiot
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.

~~~
ag_dubs
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

~~~
untog
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.

~~~
BinaryIdiot
This is still current as far as I know:
[http://www.marcusoft.net/2015/03/packagejson-and-engines-
and...](http://www.marcusoft.net/2015/03/packagejson-and-engines-and-
enginestrict.html)

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).

------
joshstrange
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)

~~~
foolfoolz
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.

~~~
dragonwriter
> 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.

------
cdnsteve
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.

~~~
matwood
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.

~~~
cdnsteve
But then you have to keep up with Babel changes too...
[http://babeljs.io/blog/2015/10/29/6.0.0/](http://babeljs.io/blog/2015/10/29/6.0.0/)

~~~
merpnderp
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?

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

~~~
callahad
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?

~~~
bonif
>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.

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

------
cmpb
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](https://twitter.com/rvagg/status/659871982670884864)
[2] [https://medium.com/@nodesource/essential-steps-long-term-
sup...](https://medium.com/@nodesource/essential-steps-long-term-support-for-
node-js-8ecf7514dbd#.wutoxcg53)

~~~
nacs
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.

------
EvanPlaice
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.

~~~
__david__
> 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.

~~~
M2Ys4U
>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](https://github.com/nodejs/nan)

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

------
alexwebb2
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.

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

~~~
rplnt
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);

~~~
arcatek
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 }

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

~~~
Keithamus
Stage 2

[https://github.com/tc39/ecma262](https://github.com/tc39/ecma262)
[https://github.com/sebmarkbage/ecmascript-rest-
spread](https://github.com/sebmarkbage/ecmascript-rest-spread)

------
amarraja
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._

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

~~~
dsp1234
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.

~~~
frik
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.

------
sarciszewski
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?

~~~
orthecreedence
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.

~~~
slasaus
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.

------
qntmfred
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...](https://nodesource.com/blog/essential-steps-long-term-support-for-
nodejs#how-long)

------
gamesbrainiac
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?

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

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

~~~
netcraft
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.

------
donpark
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.

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

~~~
diggan
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

~~~
BinaryIdiot
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.

~~~
rane
> 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](https://github.com/nodejs/readable-stream).

------
xdinomode
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

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

------
epynonymous
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

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

------
talles
Spread operator, yay!

------
amelius
Support for in-process multithreading already?

------
vonklaus
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.

~~~
dragonwriter
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.

