Live data from Hacker News

Node.js 5.0 Released

github.com

81–90 of 132 posts

Re: Node.js 5.0 Released

#81
post #57

Earlier quoted context omitted.

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?

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.

Re: Node.js 5.0 Released

#82

Earlier quoted context omitted.

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.

Re: Node.js 5.0 Released

#83
post #38
post #30

Earlier quoted context omitted.

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

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

Re: Node.js 5.0 Released

#85

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?

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.

Re: Node.js 5.0 Released

#86

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)

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"

Re: Node.js 5.0 Released

#87

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

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.

Re: Node.js 5.0 Released

#88
post #48

Earlier quoted context omitted.

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?

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.

Re: Node.js 5.0 Released

#89

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

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

Re: Node.js 5.0 Released

#90
post #63

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

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

By "npm" I assume the author meant "packages in npm", not npm itself.
Post reply on HN