Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Node.js 5.0 Released

github.com

Post reply on HN
Print view View original

121–130 of 132 posts

Re: Node.js 5.0 Released

#121

Post by cdnsteve »

bryanlarsen wrote: post #82
cdnsteve wrote: post #77

Earlier quoted context omitted.

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.

Re: Node.js 5.0 Released

#122

Post by jasnell »

BinaryIdiot wrote: post #44

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

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.

Re: Node.js 5.0 Released

#123

Post by jasnell »

BinaryIdiot wrote: post #44

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

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.

Re: Node.js 5.0 Released

#124

Post by Keithamus »

msoad wrote: post #83
arcatek wrote: post #38

Earlier quoted context omitted.

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 c…

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

Re: Node.js 5.0 Released

#125

Post by matwood »

bonif wrote: post #93
callahad wrote: post #55

Earlier quoted context omitted.

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?

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

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

Re: Node.js 5.0 Released

#126

Post by __david__ »

M2Ys4U wrote: post #116
__david__ wrote: post #98

Earlier quoted context omitted.

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

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

Re: Node.js 5.0 Released

#127

Post by BinaryIdiot »

jasnell wrote: post #122
BinaryIdiot wrote: post #44

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

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…

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

Re: Node.js 5.0 Released

#129

Post by frik »

dsp1234 wrote: post #114
frik wrote: post #89

Earlier quoted context omitted.

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.

Re: Node.js 5.0 Released

#130

Post by slasaus »

orthecreedence wrote: post #120
sarciszewski wrote: post #22

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.
Post reply on HN