23 ms·

Node.js 5.0 Released

278 points by scorchio 11y ago

gamesbrainiac 11y ago
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 11y ago
  Node now follows Semver. If you look through the changelog, there's more than a dozen changes that are breaking.
  - Touche 11y ago
    That doesn't answer the question. Node 4.0 was released a month ago. Why are there so many breaking changes in 1 month?
    - Mchl 11y ago
      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.
    - deleted 11y ago
      [deleted]
    - cmpb 11y ago
      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.
    - netcraft 11y ago
      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.
    - dragonwriter 11y ago
      > 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.
  - _ak 11y ago
    @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.
- bryanlarsen 11y ago
  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-2015-06-25 https://github.com/npm/npm/blob/master/CHANGELOG.md#v300-201...
- justncase80 11y ago
  I believe they updated the version of v8 they're dependent on, which causes them to bump the major version too.
  - justncase80 11y ago
    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.
alexwebb2 11y ago
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 11y ago
  Yes, I'm very excited about the spread operator! I've been spoiled by Firefox.
  - rplnt 11y ago
    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 11y ago
      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 11y ago
        There is a proposal for this but I'm not sure what stage that's in
        Keithamus 11y ago
        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
cdnsteve 11y ago
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.
- agumonkey 11y ago
  javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.
  - Joeri 11y ago
    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.
    - agumonkey 11y ago
      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.
- agumonkey 11y ago
  javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.
bfrog 11y ago
Uhh, wait, wasn't nodejs 4.0 only like a month ago? So are there going to be breaking changes every few months now?
- alexwebb2 11y ago
  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.
- diggan 11y ago
  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
  - deleted 11y ago
    [deleted]
  - BinaryIdiot 11y ago
    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 11y ago
      > 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.
sarciszewski 11y ago
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 11y ago
  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 11y ago
    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.
vonklaus 11y ago
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.
- dvcc 11y ago
  The major version number change doesn't mean a ton of work was done, just that there were breaking changes.
- dragonwriter 11y ago
  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.
- talles 11y ago
  People have to lose this idea that the version numbers indicates time. It doesn't. (for semver at least)
joshstrange 11y ago
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)
- jt2190 11y ago
  The LTS plan: https://github.com/nodejs/LTS https://github.com/nodejs/LTS
- sago 11y ago
  '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.
- coldtea 11y ago
  >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....
  - 11y ago
cmpb 11y ago
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-support-for-node-js-8ecf7514dbd#.wutoxcg53 https://medium.com/@nodesource/essential-steps-long-term-sup...
- nacs 11y ago
  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.
BinaryIdiot 11y ago
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.
- jessaustin 11y ago
  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.
  - 11y ago
talles 11y ago
Spread operator, yay!
amarraja 11y ago
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.
- azernik 11y ago
  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.
- frik 11y ago
  Maybe Microsoft wakes up to fix the MAXPATH limit (260 chars). Recently the improved UI of the environment variable dialog, after 25 years.
  - dsp1234 11y ago
    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 11y ago
      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.
EvanPlaice 11y ago
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.
- kylemathews 11y ago
  Probably because their sole research into this issue was seeing that a number went from 4 to 5.
- __david__ 11y ago
  > 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.
  - deleted 11y ago
    [deleted]
  - M2Ys4U 11y ago
    >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
amelius 11y ago
Support for in-process multithreading already?
qntmfred 11y ago
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-support-for-nodejs#how-long https://nodesource.com/blog/essential-steps-long-term-suppor...
fibo 11y ago
Yeah, habemus spread operator! I also hope v6 Will be full ES6. Right now classes can be user only in strict mode :(
deleted 11y ago
[deleted]
donpark 11y ago
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.
xdinomode 11y ago
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
- muzmath 11y ago
  Upgrading to 4.2.x will give you LTS.
- johnhenry 11y ago
  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 11y ago
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

278 points by scorchio 11y ago

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 11y ago
Node now follows Semver. If you look through the changelog, there's more than a dozen changes that are breaking.
- Touche 11y ago
  That doesn't answer the question. Node 4.0 was released a month ago. Why are there so many breaking changes in 1 month?
  - Mchl 11y ago
    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.
  - deleted 11y ago
    [deleted]
  - cmpb 11y ago
    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.
  - netcraft 11y ago
    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.
  - dragonwriter 11y ago
    > 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.
- _ak 11y ago
  @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.
bryanlarsen 11y ago
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-2015-06-25 https://github.com/npm/npm/blob/master/CHANGELOG.md#v300-201...
justncase80 11y ago
I believe they updated the version of v8 they're dependent on, which causes them to bump the major version too.
- justncase80 11y ago
  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.

alexwebb2 11y ago

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 11y ago
Yes, I'm very excited about the spread operator! I've been spoiled by Firefox.
- rplnt 11y ago
  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 11y ago
    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 11y ago
      There is a proposal for this but I'm not sure what stage that's in
      - Keithamus 11y ago
        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

cdnsteve 11y ago

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.

agumonkey 11y ago
javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.
- Joeri 11y ago
  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.
  - agumonkey 11y ago
    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.
agumonkey 11y ago
javascript pace feels so overwhelming it makes me enjoy reading Java 6 specs.

bfrog 11y ago

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

alexwebb2 11y ago
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.
diggan 11y ago
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
- deleted 11y ago
  [deleted]
- BinaryIdiot 11y ago
  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 11y ago
    > 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.

sarciszewski 11y ago

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 11y ago
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 11y ago
  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.

vonklaus 11y ago

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.

dvcc 11y ago
The major version number change doesn't mean a ton of work was done, just that there were breaking changes.
dragonwriter 11y ago
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.
talles 11y ago
People have to lose this idea that the version numbers indicates time. It doesn't. (for semver at least)

joshstrange 11y ago

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)

jt2190 11y ago
The LTS plan: https://github.com/nodejs/LTS https://github.com/nodejs/LTS
sago 11y ago
'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.
coldtea 11y ago
>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....
- 11y ago

cmpb 11y ago

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-support-for-node-js-8ecf7514dbd#.wutoxcg53 https://medium.com/@nodesource/essential-steps-long-term-sup...

nacs 11y ago
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.

BinaryIdiot 11y ago

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.

jessaustin 11y ago
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.
- 11y ago

talles 11y ago

Spread operator, yay!

amarraja 11y ago

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.

azernik 11y ago
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.
frik 11y ago
Maybe Microsoft wakes up to fix the MAXPATH limit (260 chars). Recently the improved UI of the environment variable dialog, after 25 years.
- dsp1234 11y ago
  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 11y ago
    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.

EvanPlaice 11y ago

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.

kylemathews 11y ago
Probably because their sole research into this issue was seeing that a number went from 4 to 5.
__david__ 11y ago
> 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.
- deleted 11y ago
  [deleted]
- M2Ys4U 11y ago
  >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

amelius 11y ago

Support for in-process multithreading already?

qntmfred 11y ago

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

fibo 11y ago

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

deleted 11y ago

[deleted]

donpark 11y ago

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.

xdinomode 11y ago

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

muzmath 11y ago
Upgrading to 4.2.x will give you LTS.
johnhenry 11y ago
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 11y ago

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