That's because it is a press release. There is a changelog and release notes too, it just happens that whoever submitted this chose to link to a press release instead.
babel sucks - I never though I could hate something so strongly.
Just today I had to deal with the fact that babel wraps ALL your generators in some shit function.
Why ? just why ? generation function was supported in browsers longer then the age all the babel maintainers combined.
The worst part is I do not use babel myself - I wouldn't touch it with a ten foot pole but am forced to use it due to my stupid cowokers writing everything using babel - ( why does babel need .babelrc file ?? - is babel such a prominent part of your life that you need .rc files ?? and why does the .rc file need to be specified in every freaking folder ! )
1) babel's docs are also terrible
2) The people maintaining babel seem to actively market babel and then at the same time ignore questions and requests for better docs from the community.
3) Slowest compiler I have had the pleasure of dealing with - my babel watch process consumes a grand total of 150 MB of memory !!
Generator functions do not have total browser support yet. IE11 does not support them. Node 6 is actually the first Node version with total support for them:
Even if generation functions are not supported - its a tradeoff that is worth making since very few of our users use IE11.
That is not my main concern. Babel can wrap the code in 10 functions for all I care ( performance is also not a concern since we are not sending rockets to mars - just another technology sweatshops trying to sell viagra )
The wrapped function throws errors - since apparently you need to download some babel plugins for it to work. (ノಠ益ಠ)ノ彡
>That is not my main concern. Babel can wrap the code in 10 functions for all I care ( performance is also not a concern
Babel code is actually faster than the native implementation of most of the ES2015/6 features atm.
>The wrapped function throws errors - since apparently you need to download some babel plugins for it to work. (ノಠ益ಠ)ノ彡
So you forgot to download some plugins and it's Babel's fault?
And, sorry, where does the entitlement come from? It's you who needs and uses Babel, even imperfect and buggy as it is, to get the job done, not the inverse.
- You can put the babel configuration in your package.json.
- babel by itself doesn't actually do anything. It depends on the preset you chose. There are now a bunch of presets that leave parts of ES6 alone (i. e. to use ES6 import with webpack).
- I have actually never looked at the docs :). Never had a problem with it (unlike the package manager from config file hell, i.e. webpack).
Yeah, webpack can be not fun at all... but, depending on your needs it can do what you want. Being able to configure CSS processed, with some stuff inlined, required from your components is pretty sweet...
Please resist commenting about being downvoted.
It never does any good, and it makes boring reading.
Please don't bait other users by inviting them to downvote
you or announce that you expect to get downvoted.
I like the idea of Babel, but would prefer it as a sort of compile-for-production step. The performance and debugging complexity don't seem worth it as part of the development process. Seems like it'd now be possible w/ Node v6 and a modern browser to develop "live" in (93% of) ES6 and then just Babel-compile to ES5 for backwards compat at the end?
I agree with you in part. Babel is not something I'm fond of (I can't seem to wrap my brain around phabricator as an issue tracker).
In fairness though, you can configure babel to use native generators if you intend to only support platforms which implement them. However, generators have also not been well supported for very long: http://kangax.github.io/compat-table/es6/#test-generators
You don't need a .babelrc file in every directory, your coworkers are doing something wrong. Also, in that .babelrc file you can customize the generator behaviour to your heart's content - if your coworkers have chosen bad presets then your issue is with them, not Babel.
I agree that Babel is slow. Hey, there's always Buble: http://buble.surge.sh/, but then you lose a lot of configurability. There's always a trade-off.
And yes, the generator stuff is far more verbose than it needs to be, but because Babel is trying to cover all browsers by default. It's like jQuery. Good news is you can opt out.
It'll probably be about 5-6 years until all of the features I use today are in supported in browsers and the last of IE has fallen off. I'm surprised SNI haven't pushed XP and Android < 3 out faster.
On a related note, does anyone know if there's a way to tell Babel that your compilation target is Node.js v6.0 and only have it compile stuff that isn't natively supported yet?
Edit: Thanks for all the answers. I just went through the list of unsupported features and as I'm not using any of the remaining 7%, I might be able to get rid of Babel during development if I'm lucky.
There's one remaining problem: V8 ES6 support is quite new and less optimized. If you're looking for optimal performance, you'll be transpiling for a long time (or possibly forever, 'cause those ES7 features are tempting, aren't they?)
In fairness, the babel approach to module handling is probably better than an in-browser es6 module implementation, or what may follow... compatibility with npm packages (cjs) will be significant for a while.
My understanding is that V8 will provide hooks that parse the module imports, then delegate to the embedder to fetch the actual source code and hand it back to V8 to load. I'd expect that the Node implementation of these hooks would work the same way as the existing require() machinery, so that existing libraries will continue to work.
The javscript version of the hedonic treadmill ensures there will always be a juicy new feature that node/browsers don't have yet but Babel/other transpilers usually will. Just because it's 93% of the way there on ES6 at this moment doesn't mean that a few months from now people, your team included, won't be clamoring to be able to write with the new sweet features from ECMAScript 2017 or whatever. The only solution is to keep Babel a part of your stack perpetually and really that's not so bad in my opinion.
Remember that performance with Babel transpiled code is still sometimes faster (in some cases, substantially so) than the native ES6 implementations, as optimizing continues on V8's end.
And be sensible about how much transpilation you want, you can use newer presets that don't need to transform the code as much, while still having the ability to layer in newer features (async/await, ES7, etc).
I don't know the answer, but this would be useful in general given that much of ES2015 is supported by Firefox, Chrome and Edge. It's enough that I can imagine having an "evergreen browsers" build and an "everybody else" build.
Instead of Babel, you might want to look at Rollup.js for ES6 module support. [1]
You can have Rollup spit out CommonJS require commands for things that aren't part of your project, or you can use rollup-plugin-commonjs to wrap your entire app into one big bundle, including the CommonJS includes.
And as much faster as Node 6 has gotten with module importing, it almost can't be as fast as Rollup's module loader, which is more optimal than Browserify and WebPack, in that ES6 modules don't even get wrapped in "requires", but instead included inline. It just parses the code to ensure no variable names collide.
I've been a front end developer for, well, quite a while, and in that time we've gone from cycles of around a decade (thank you IE6!) for new versions of JS to something closer to a couple of years.
On a more serious note this really is an awesome release. Kudos to everyone that works on Node.js!
Ever since the "reunification" of node.js/io.js there's been a whirlwind of great activity both in adding features as well as LTS releases (which are critical for long term adoption of the platform).
Sidenote - was just messing with Homebrew a few days ago, and found it a little bizarre that all of the recipes are in source control and require a pull to update, rather than being on a server somewhere.
Just make sure to update your package.json to take a hard dependency on Node 6+ if you do that:
{ "engines" : { "node" : ">=6.0.0" } }
This will make it so that ES6-compat is assumed and TS won't transpile ES6 functionality, but it will use commonjs for modules, which means your TS will almost be a 1:1 mapping with the compiled JS and everything should just work.
Personal pet peeve: Please don't set the node engine field in npm packages. It potentially breaks your package whenever there's a new release candidate because `node@7.0.0-rc.1` is less than (!) `node@6.0.0` when it comes to npm's handling of this field.
I guess the argument is that, if you're going to use ">=6.0.0" to choose a version of node.js, and your options are 6.1.0 and 7.0.0-rc1, you don't want a random release candidate. But if you're going to use it to verify an existing version of node.js, a 7.0.0-rc1 that someone else chose should be considered acceptable. Their semver rules can't distinguish these two cases.
PEP 440 seems to handle this by decoupling the prerelease rules and the version-comparison rules: https://www.python.org/dev/peps/pep-0440/#handling-of-pre-re... "Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release."
Sooo that's like, an npm design flaw then? If you don't specify the engine field, someone using an older version of node will just get incorrect failures and think your package is broken. I'd rather specify the engine and give a clear error to all users on a version of Node.js older than 1 day than to make it work for users on Node RCs. Although it would be nice if npm made it possible to support both sets of users.
What does this type of condescending bile add to the discussion? Thousands of companies successfully use PHP and node to write excellent software every day. If you despise node so fervently, why are you even engaging in a thread about the latest node release?
Personally, I prefer ruby whenever its an option, but I've worked with node in the past and it's a decent platform that worked very well for the company (a commercial app servicing about 840k api and page requests per month).
So negative opinions about '*' should never be expressed?
JavaScript is a terrible language, and imho es2015 fixes a lot of broken stuff in the only backwards-compatible way it can. That said, I find the entire micropackage culture around npm and node, coupled with the hundreds of packages that typically constitute build scripts for even a smallish node project make me realize just how brittle it is compared to competing platforms.
There's a difference between being negative with specific complaints versus hyperbolic, drive-by FUD.
Regarding your own complaints with Node. You're over-generalising. Nobody says you must use small modules. Larger libraries and frameworks exist. Same goes for build scripts. Also read this to get more context on small modules: https://github.com/sindresorhus/ama/issues/10
"Negative opinions" are fine. Heaping on condescending substance-free exclamations of ridicule in the middle of a thread about a specific issue regarding a platform you don't even use is just toxic arrogance.
Your "micropackage" complaint is daft; if you don't like small modules don't use them. Why is the language to blame for free, open-source code that you don't have to use? How is this even a legitimate complaint? You don't need hundreds of packages for anything and you can find examples of this in any language.
What language/eco-system isn't horrible, honestly? In some way? What's your "ideal" stack?
Professional, I have used or am using C/C++, Python, Ruby, Javascript, some Java, some C#, Golang.
Our of all of those the only one I don't really hate is Golang. In every other language/eco-system I can point to at least a dozen things that are awful. In Golang - maybe only 9.
Node has NPM with a huge eco-system. It's fast. Javascript, if written correctly, can be a pleasure to use, IMO. And even if you can't use it idiomatically for some reason, you can use Cofeescript/Typescript or whatever that forces some sort of code structure/discipline.
Node itself is decent if you understand how to ignore callback-pyramid-of-death with Promises and reactive-type programming.
Not all suck, at least not as much as the one in the discussion...
I have used most of those you listed, and some esoteric/legacy/proprietary stuff.
To me, with all its flaws, C#, Java, Scala, Python were the best, with goodness decreasing.
I need to try F# as I feel I'd like it very much. Generally I believe in static type systems with proper generics support catching a lot of bugs up front, and are a pleasure to use, as my personal experience also shows this. You may not have enough experience with Java, or especially with C#, and I suspect that you may even find some of the greatest features there mere annoyances.
After being an experienced C programmer and having same JS experience I can say JS has the much same problems. Bad design decisions initially. Then sticking to the legacy. Lack of expressive power.
Writing correct code in JS or C is a struggle. For some reason both are overrepresented here on HN.
Lack of proper module module system makes JS inferior to most modern languages (C#, Go, Rust,...). (npm solves some of it), and it could be continued for pages, but for a believer/zealot it wouldn't matter.
Strongly recommend you get used to it. JavaScript is the universal language of the future. What can be written in JS will be written in JS. This is just a fact my man. Not because it's superior to other languages, it's simply because it is more cost effective to use. For example, at my current company, we are now using a Node Microservices architecture, Cassandra, Redis, Relay, GraphQL, and React. We're doing all our mobile using React Native. We were a Rails Angular shop before. All our engineers are now full-stack JS. We were able to get rid of 75% of our engineers using this stack...and then hire much higher quality engineers...JS experts. I can't tell you what a pleasure it is to work with this stack vs. something like Rails + Angular. And as for performance, it moves like nothing I've ever seen before. Warp speed brother. JS is the future my man. It's the only programming language I would invest my time in learning...i mean if you're concerned about job security and all. If not, I would spend my time learning Elixir and Phoenix. Also TensorFlow.
There is/was a vote on this pretty soon. We are deciding how modules would work - with a new file extension? With a module.json? With a separate entry entry in package.json? Lots of decisions to be made :)
ES6 didn't define precisely how module loading worked, one of the reasons it isn't actually implemented yet. And there are actual reasons why the method babel currently uses won't precisely match the actual implementations (see hierarchal v flat dependencies)
Wow, a new extension for ES modules? That seems really unfortunate.
Why can't node parse a file to detect if it's a module? The presence of a top-level import or export means it's a module. If it's not, then the parsed file can be kept if the file is also in strict mode. If it's sloppy, it'll have to be re-parsed. Seems like a small penalty if the goal is to enable migration.
Also, why worry about ES modules importing Common JS? Just disallow that and let projects migrate to ES modules bottom-up. Then you don't have to worry about executing a Common JS module to determine what its exports are or circular dependency problems.
There is a pretty epic thread that I suggest you just read the tail end of https://github.com/nodejs/node-eps/pull/3#issuecomment-21476... . Basically we tried detection via source code as the first proposal; ambiguities at runtime that do not throw errors make it absolutely impossible to do safely, performance problems, and tooling integration problems.
What sort of compatibility issues? Most packages update to work with new Node releases fairly quickly. Usually the packages that have compatibility issues are ones with native C++ bindings. If you `npm rm` the package and reinstall it, it will usually build correctly for the latest Node/V8 release.
Further, if you have a project that for whatever reason is not feasible to update to run on modern Current Node, you can use `nvm` or `n` to choose which Node release you want to use: i.e. `nvm exec 0.12 node old-project.js` and `nvm exec 6.0 node fresh-project.js`. v6 (and the versions that preceded it) has made Javascript really enjoyable to write.
Our biggest issue is to get off node 0.12, we need to get off protractor 2, and some of our protractor tests fail on protractor 3 for reasons no one has yet figured out. The only clue is a note saying selenium webdriver 2.48 changed how its control flow worked, but nowhere is what changed from 2.47 to 2.48 documented.
thanks, I will look deeper into it. I could not install certain packages even with a fresh and clean new node.js. NVM is not the issue (I know node version handlers like nvm or tj/n). I just wondered if I'm the only one who had this compatibility issues.
It might be worth trying to get to 4.2.0, which was the first LTS [1] release (due to the change in versioning, that's only six months older than 4.2.0).
Somewhat related there is no optimization for passing arbitrary length arrays with `...` to function having `...rest` as the last argument, which means [].splice is still a footgun:(
It is, but Clojure uses it, because it cannot really do Tail Call Optimization due to constraints on the JVM. Therefore "recur" is required to keep the Stack from overflowing.
I'd like to take a moment, and tell all the javascript/node haters I've run into here and on reddit, to suck a big fat dick, and I fucking hate you so bad.
We've banned this account for repeatedly violating the HN guidelines. If you don't want it to be banned, you're welcome to email hn@ycombinator.com. We're happy to unban people when there's reason to believe that they'll only post civil, substantive comments in the future.
173 comments
[ 3.0 ms ] story [ 223 ms ] threadNotable changes summarized here: https://github.com/nodejs/node/pull/6383
[0] https://github.com/nodejs/node/pull/6383#issue-151012738
Just today I had to deal with the fact that babel wraps ALL your generators in some shit function.
Why ? just why ? generation function was supported in browsers longer then the age all the babel maintainers combined.
The worst part is I do not use babel myself - I wouldn't touch it with a ten foot pole but am forced to use it due to my stupid cowokers writing everything using babel - ( why does babel need .babelrc file ?? - is babel such a prominent part of your life that you need .rc files ?? and why does the .rc file need to be specified in every freaking folder ! )
1) babel's docs are also terrible
2) The people maintaining babel seem to actively market babel and then at the same time ignore questions and requests for better docs from the community.
3) Slowest compiler I have had the pleasure of dealing with - my babel watch process consumes a grand total of 150 MB of memory !!
Edit - had to follow HN guidelines
https://kangax.github.io/compat-table/es6/
That is not my main concern. Babel can wrap the code in 10 functions for all I care ( performance is also not a concern since we are not sending rockets to mars - just another technology sweatshops trying to sell viagra )
The wrapped function throws errors - since apparently you need to download some babel plugins for it to work. (ノಠ益ಠ)ノ彡
Generators are unsupported on all of them.
Babel code is actually faster than the native implementation of most of the ES2015/6 features atm.
>The wrapped function throws errors - since apparently you need to download some babel plugins for it to work. (ノಠ益ಠ)ノ彡
So you forgot to download some plugins and it's Babel's fault?
And, sorry, where does the entitlement come from? It's you who needs and uses Babel, even imperfect and buggy as it is, to get the job done, not the inverse.
Its the entire web community writing code in a barely function compiler.
So maybe not the best person to comment on the state of its tools?
>Its the entire web community writing code in a barely function compiler.
"I didn't include some plugins so the compiler couldn't work" != "barely functioning compiler".
- babel by itself doesn't actually do anything. It depends on the preset you chose. There are now a bunch of presets that leave parts of ES6 alone (i. e. to use ES6 import with webpack).
- I have actually never looked at the docs :). Never had a problem with it (unlike the package manager from config file hell, i.e. webpack).
Which unfortunately loses the ES7 features.
In fairness though, you can configure babel to use native generators if you intend to only support platforms which implement them. However, generators have also not been well supported for very long: http://kangax.github.io/compat-table/es6/#test-generators
I agree that Babel is slow. Hey, there's always Buble: http://buble.surge.sh/, but then you lose a lot of configurability. There's always a trade-off.
And yes, the generator stuff is far more verbose than it needs to be, but because Babel is trying to cover all browsers by default. It's like jQuery. Good news is you can opt out.
When I look at the compat tables, everything is getting green, looks like a bright future, without the need of Babel anymore.
But I find myself using post-ES2015 features all the time, because, why not? Babel gets me the latest fix.
(static) class properties, decorators, bind... Also JSX! Even if all browsers are completely on ES2015 in the next months, I can't throw Babel out :D
But luckily it seems like the next ES releases are all much smaller, so maybe the browser-manufacturers will have caught up in 2016...
Edit: Thanks for all the answers. I just went through the list of unsupported features and as I'm not using any of the remaining 7%, I might be able to get rid of Babel during development if I'm lucky.
Edit 2: Oops, still no es6 module support :(
At least exponentiation is slightly cool. Hasta la ES8 siempre I guess.
And be sensible about how much transpilation you want, you can use newer presets that don't need to transform the code as much, while still having the ability to layer in newer features (async/await, ES7, etc).
https://www.npmjs.com/package/babel-preset-es2015-auto
So take the Node 6.0 compatibility table, find out what features it supports and create a "Babel preset" that has those excluded.
http://node.green/
https://github.com/jhen0409/babel-preset-es2015-node6
Also opened a PR for discussion about adding an environment award preset in babel or supporting it in core at https://github.com/babel/babel/pull/3476.
Maybe an http2 server that uses browser detection to push polyfills so that your app can just assume everything works without transpiling up front?
I'm super hopeful http2 with es2015 modules will make web dev tooling drastically more streamlined in the nearish future.
You can have Rollup spit out CommonJS require commands for things that aren't part of your project, or you can use rollup-plugin-commonjs to wrap your entire app into one big bundle, including the CommonJS includes.
And as much faster as Node 6 has gotten with module importing, it almost can't be as fast as Rollup's module loader, which is more optimal than Browserify and WebPack, in that ES6 modules don't even get wrapped in "requires", but instead included inline. It just parses the code to ensure no variable names collide.
[1] http://rollupjs.org
But yeah, I'm not seeing where the 6.0 was cut. It doesn't appear on their releases tab: https://github.com/nodejs/node/releases
Edit: It's released!
New one is running, and should be out soon-ish.
I assumed that meant it was not yet downloadable.
The future, as I see it, is incredibly bright.
Edit: of course right after I say it isn't released, it is released. :)
Release post: https://nodejs.org/en/blog/release/v6.0.0/
Ever since the "reunification" of node.js/io.js there's been a whirlwind of great activity both in adding features as well as LTS releases (which are critical for long term adoption of the platform).
https://nodejs.org/en/
Current formula still points to v5.11: https://github.com/Homebrew/homebrew-core/blob/master/Formul...
EDIT: PR created: https://github.com/Homebrew/homebrew-core/pull/633
Sidenote - was just messing with Homebrew a few days ago, and found it a little bizarre that all of the recipes are in source control and require a pull to update, rather than being on a server somewhere.
https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...
> all of the recipes are in source control and require a pull to update AND so they are on a server somewhere.
And if you don't want generators transformed, then why are you using the regenerator plugin?
http://babeljs.io/docs/plugins/transform-regenerator/
Maybe you should have bothered to read the documentation you claim doesn't exist. Or maybe you should help out your coworkers by quitting your job.
https://news.ycombinator.com/newsguidelines.html
https://news.ycombinator.com/newswelcome.html
We detached this comment from https://news.ycombinator.com/item?id=11574894 and marked it off-topic.
Just make sure to update your package.json to take a hard dependency on Node 6+ if you do that:
This will make it so that ES6-compat is assumed and TS won't transpile ES6 functionality, but it will use commonjs for modules, which means your TS will almost be a 1:1 mapping with the compiled JS and everything should just work.I guess the argument is that, if you're going to use ">=6.0.0" to choose a version of node.js, and your options are 6.1.0 and 7.0.0-rc1, you don't want a random release candidate. But if you're going to use it to verify an existing version of node.js, a 7.0.0-rc1 that someone else chose should be considered acceptable. Their semver rules can't distinguish these two cases.
PEP 440 seems to handle this by decoupling the prerelease rules and the version-comparison rules: https://www.python.org/dev/peps/pep-0440/#handling-of-pre-re... "Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release."
It is so PHPsque.
No sane people should use it for anything serious, except some lightweight browser scripting.
I cannot grok how can people chose this stack to create any product in it.
Personally, I prefer ruby whenever its an option, but I've worked with node in the past and it's a decent platform that worked very well for the company (a commercial app servicing about 840k api and page requests per month).
I just don't understand the hate.
JavaScript is a terrible language, and imho es2015 fixes a lot of broken stuff in the only backwards-compatible way it can. That said, I find the entire micropackage culture around npm and node, coupled with the hundreds of packages that typically constitute build scripts for even a smallish node project make me realize just how brittle it is compared to competing platforms.
Regarding your own complaints with Node. You're over-generalising. Nobody says you must use small modules. Larger libraries and frameworks exist. Same goes for build scripts. Also read this to get more context on small modules: https://github.com/sindresorhus/ama/issues/10
Your "micropackage" complaint is daft; if you don't like small modules don't use them. Why is the language to blame for free, open-source code that you don't have to use? How is this even a legitimate complaint? You don't need hundreds of packages for anything and you can find examples of this in any language.
Professional, I have used or am using C/C++, Python, Ruby, Javascript, some Java, some C#, Golang.
Our of all of those the only one I don't really hate is Golang. In every other language/eco-system I can point to at least a dozen things that are awful. In Golang - maybe only 9.
Node has NPM with a huge eco-system. It's fast. Javascript, if written correctly, can be a pleasure to use, IMO. And even if you can't use it idiomatically for some reason, you can use Cofeescript/Typescript or whatever that forces some sort of code structure/discipline.
Node itself is decent if you understand how to ignore callback-pyramid-of-death with Promises and reactive-type programming.
I have used most of those you listed, and some esoteric/legacy/proprietary stuff.
To me, with all its flaws, C#, Java, Scala, Python were the best, with goodness decreasing. I need to try F# as I feel I'd like it very much. Generally I believe in static type systems with proper generics support catching a lot of bugs up front, and are a pleasure to use, as my personal experience also shows this. You may not have enough experience with Java, or especially with C#, and I suspect that you may even find some of the greatest features there mere annoyances.
After being an experienced C programmer and having same JS experience I can say JS has the much same problems. Bad design decisions initially. Then sticking to the legacy. Lack of expressive power.
Writing correct code in JS or C is a struggle. For some reason both are overrepresented here on HN.
Lack of proper module module system makes JS inferior to most modern languages (C#, Go, Rust,...). (npm solves some of it), and it could be continued for pages, but for a believer/zealot it wouldn't matter.
Any solution that requires extra work (file extension, another file to maintain) is a non-starter.
Frankly it should work how Babel transpiles it - because there's no reason for it not to.
Yet they were solved for that.
Why can't node parse a file to detect if it's a module? The presence of a top-level import or export means it's a module. If it's not, then the parsed file can be kept if the file is also in strict mode. If it's sloppy, it'll have to be re-parsed. Seems like a small penalty if the goal is to enable migration.
Also, why worry about ES modules importing Common JS? Just disallow that and let projects migrate to ES modules bottom-up. Then you don't have to worry about executing a Common JS module to determine what its exports are or circular dependency problems.
Further, if you have a project that for whatever reason is not feasible to update to run on modern Current Node, you can use `nvm` or `n` to choose which Node release you want to use: i.e. `nvm exec 0.12 node old-project.js` and `nvm exec 6.0 node fresh-project.js`. v6 (and the versions that preceded it) has made Javascript really enjoyable to write.
Feel free to try: https://github.com/SeleniumHQ/selenium/compare/selenium-2.47...
It's a dependency of a dependency with multiple language versions in the one repository.
1: https://nodesource.com/blog/essential-steps-long-term-suppor...
Example app running v6.0.0: http://nodejs600.appspot.com/
Somewhat related there is no optimization for passing arbitrary length arrays with `...` to function having `...rest` as the last argument, which means [].splice is still a footgun:(
Are there any tools that statically or otherwise checks any potentially breaking pieces in the Node v4+ codebase/dependencies?
Is there any tools that statically or otherwise checks any breaking potentially pieces in the Node v4+ codebase/dependencies?