I've not tried it but there is this preset https://github.com/jhen0409/babel-preset-es2015-node6

Babel 6+ is configuration hell, you can do whatever you want provided you have the patience/knowledge to plug together the right plugins.

So take the Node 6.0 compatibility table, find out what features it supports and create a "Babel preset" that has those excluded.

...or just use a preset someone else made:

https://github.com/jhen0409/babel-preset-es2015-node6

Now that's thinking the npm way

Especially since this preset is two lines long, referring to two other plugins

It looks like the primary thing missing is 'iterator closing'.

http://node.green/

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.

[1] http://rollupjs.org

As others have mentioned there are node and browser specific presets you can use.

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.

I'd love to see a Babel sort of thing that backs away from transpiling as much as possible and functions more as execution time polyfill.

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.

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.

It'd be not super useful yet, because there's no good way to minify ES2015 code.

Isn't Babel 93% redundant on the server side now? If you're not very dependent on the last 7% I'd just remove it.

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

Can't wait on that Exponentiation Operator and A.p.includes!

As you indicated, almost none of what was once called ES7 made it into the final spec: http://www.2ality.com/2016/01/ecmascript-2016.html

At least exponentiation is slightly cool. Hasta la ES8 siempre I guess.

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

The big missing thing is modules, which aren't in the kangax compatibility table.

ES2015 did not include a loader specification, only a module specification. https://github.com/nodejs/node-eps/blob/master/002-es6-modul... is the interop that will be present for node but it is outside of JS spec itself.

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.

I use it to transform async/await into generators for Koa. The module syntax is also much nicer to use.

Came to note the same... really like async functions.

Maybe I've got Stockholm syndrome but I prefer the module.exports style.

How will es6 module support work in the long run, will node.js have to support two modules systems?

Hmm... I get the same thing on the REPL. Can you share what you see?

Oops, I was mistaken about that. It looks like all core modules are in local scope when in the REPL which is why `os.arch()` was working.

This should do what you want. Don't know if it needs to be updated for v6.0

https://www.npmjs.com/package/babel-preset-es2015-auto