3 ms·
I'm glad people are pushing the envelope on JS build tooling, and not giving in to the "we need to freeze the toolspace now" contingent. I feel like the mainstr
by _greim_ 11y ago
I'm glad people are pushing the envelope on JS build tooling, and not giving in to the "we need to freeze the toolspace now" contingent. I feel like the mainstream build tools have been interesting, but nobody has got it all figured out yet.
One question, if this is ES6, then why:
exports.foo = function* () {}
...instead of:
export function* foo() {}
?
- kevrom 11y agoDoing the latter would require you to use something like babel-node, whereas the former is all available without any such wrapper/compiling.
- robinricard 11y agoThe first snippet uses the CommonJS [1] standard (a way to import packages into a JS file that is used by Node, webpack or browserify for example). The second snippet uses ES6 modules [2]. Babel actually transpiles those ES6 modules into CommonJS modules when used in a Node.js environment (which is the case with a build tool). Since even IO.js doesn't support ES6 modules for now and you're likely to use a build tool in order to use babel, you shouldn't use ES6 modules in a build file. [1]: http://www.commonjs.org/ http://www.commonjs.org/ [2]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- bucaran 11y agoThe folks below already gave you the answer, but we are considering adding support for Flyfiles written in ES6 now. It's intrusive and opinionated, and although one of the reasons I like auto loading plugins is so that Flyfiles end up looking as agnostic as possible despite using ES5, I think it would be awesome to have ES6 Flyfiles.