5 ms·
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 native
by olalonde 11y ago
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.
Edit 2: Oops, still no es6 module support :(
- benologist 11y agoIsn't Babel 93% redundant on the server side now? If you're not very dependent on the last 7% I'd just remove it.
- veeti 11y agoI use it to transform async/await into generators for Koa. The module syntax is also much nicer to use.
- matt4077 11y agoThere'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?)
- grayrest 11y agoCan't wait on that Exponentiation Operator and A.p.includes!
- SerpentJoe 11y agoAs 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 http://www.2ality.com/2016/01/ecmascript-2016.html At least exponentiation is slightly cool. Hasta la ES8 siempre I guess.
- nostrademons 11y agoThe big missing thing is modules, which aren't in the kangax compatibility table.
- tracker1 11y agoIn 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.
- nostrademons 11y agoMy 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.
- bmeck 11y agoES2015 did not include a loader specification, only a module specification. https://github.com/nodejs/node-eps/blob/master/002-es6-modules.md 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.
- savanaly 11y agoThe 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.
- nemild 11y agoRemember 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).
- dangoor 11y agoI 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.
- streptomycin 11y agoIt'd be not super useful yet, because there's no good way to minify ES2015 code.
- iamflimflam1 11y agoThis 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 https://www.npmjs.com/package/babel-preset-es2015-auto
- Touche 11y agoBabel 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.
- jsprogrammer 11y agoIt looks like the primary thing missing is 'iterator closing'. http://node.green/ http://node.green/
- untog 11y ago...or just use a preset someone else made: https://github.com/jhen0409/babel-preset-es2015-node6 https://github.com/jhen0409/babel-preset-es2015-node6
- emgee3 11y agoI've not tried it but there is this preset https://github.com/jhen0409/babel-preset-es2015-node6 https://github.com/jhen0409/babel-preset-es2015-node6
- joombaga 11y agoHmm... I get the same thing on the REPL. Can you share what you see?
- olalonde 11y agoOops, 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.
- hzoo 11y agoAs 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 https://github.com/babel/babel/pull/3476.
- fooey 11y agoI'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.
- SomeCallMeTim 11y agoInstead 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 http://rollupjs.org
- Scarbutt 11y agoHow will es6 module support work in the long run, will node.js have to support two modules systems?
- bmeck 11y agohttps://github.com/nodejs/node-eps/blob/master/002-es6-modules.md https://github.com/nodejs/node-eps/blob/master/002-es6-modul...