Support ES6

[phated]

This work has been discussed and issue opened over at gulpjs/interpret#8

[sindresorhus]

👍 Would be awesome to have this work transparently.

[domenic]

https://github.com/shinnn/gulpur

[phated]

@domenic a registration module needs to be provided for interpret. That's why I was looking at 6to5. I'd like to use Traceur but there isn't a module and we can't use makeDefault

[geekflyer]

👍 looking forward for it.

[phated]

ES6 should be usable against master now. Try it out and let me know how it works.

[geekflyer]

@phated I'm already using the gulp4.0 branch. Is it possible to get this there too?
Thx and Best Regards Christian

[phated]

@geekflyer c1cf3cb 😉

[geekflyer]

@phated Doesn't work. I get No gulpfile found . I think it's because the gulp-cli#4.0 branch does not have the updated node-interpret dependency, but still points to "interpret": "^0.3.2". :-)

[geekflyer]

apparently merging the gulp-cli master into 4.0 solves the problem. The second problem is the gulp-cli check complains about the local gulp version (4.0.0-alpha), probably because he doesn't understand the alpha thing :-)
Unsupported gulp version 4.0.0-alpha

[phated]

Should be working now. Thanks for catching those.

[geekflyer]

I can confirm it works now (gulpfile has to end with .es6 or .es instead of .js).
It also works for for dynamically loaded subtask files, which are just ending with .js.
Thx

[ilanbiala]

@geekflyer @phated is the .es6 extension a real thing, or just for transpilers? Is .js not going to be used anymore? Is there no way to detect ES6 in a JS file?

[geekflyer]

@ilanbiala I don't think .es6 is a real / offical extension, it's just a simple way to tell your CLI or transpiler, "hey this file probably has some ES6 code in there".

The other alternative would be to simply transpile all .js files or scan all .js files for ES6 syntax - both would cause not negligible overhead as oppose to just looking for the file extension .es6.

In my own project (which has a central gulpfile + ~10 subfiles) I could see the startup of gulp to slow down about ~1 second when using .es6, because the 6to5 transpiler has to be initialized etc.. It would not make sense to slow down everybody's gulp startup through code scanning etc. when they don't use ES6.

[geekflyer]

Note that also other transpilers (coffee, JSX, TypeScript) are supported for gulpfiles - the extension always indicates which transpiler to use. Basically everything which is listed here is supported:
https://github.com/tkellen/node-interpret/blob/master/index.js

[theefer]

SystemJS relies on format detection based on hints present in the files (e.g. "format es6"; at the top of the file) or regexp to look for any top-level ES6 import or export.

[domenic]

I've been thinking about this for a while, and I stumbled upon what IMO is the right answer: the extension should be .6to5, or possibly .6to5.js. This is good in a number of ways:

• It avoids promoting a bogus .es6 extension that places language versions in the filenames, which is very bad.
• It avoids people thinking that their code is necessarily compatible with ES6, when in reality it's of the 6to5 dialect. 6to5 has a stated commitment to compliance, but the fact remains that there are going to be many edge cases that work in 6to5 that do not work in ES6.
• It aligns with the fact that, as people have noted in this thread, the file extension for the gulpfile is a signaling mechanism for what transpiler to use---it doesn't actually have anything to do with the file type in the usual sense.
• It leaves room for other ES6 transpilers, in theory. (In practice I doubt this would be introduced.)

[sindresorhus]

I've been thinking about this for a while, and I stumbled upon what IMO is the right answer: the extension should be .6to5, or possibly .6to5.js.

👍

[geekflyer]

👍 for .6to5.js

Also has the advantage that I don't have to tell my IDE / Editor explicitly that .es6 is actually just JavaScript.

[arthurvr]

I'm +1 for .6to5.js

[phated]

I have no opinions on this and am open to changing it to .6to5.js (breaking change in interpret) but should we still register on .js when it is loaded? I think we should.

My proposal is to register on the extensions: .6to5, .6to5.js and .js but only when a .6to5 or .6to5.js file is loaded.

I also need to check liftoff and see if it supports double extensions, as I know it needed to be fixed in node-rechoir.

[domenic]

I don't entirely understand what "register on .js when it is loaded" means (especially the "loaded" part). But I think it seems bad since then in e.g. an io.js environment how could you use the native ES6 features?

[geekflyer]

@domenic He means, that when the gulpfile.6to5.js is loaded all subsequently required .js files (like subtasks1.js, subtasks2.js etc.) should also be transpiled using 6to5, even though they don't have the special 6to5 extension (except node_modules folder). This is also the default behaviour of 6to5's require hook which is being used in gulp: https://6to5.org/docs/usage/require/
I agree and like this behaviour - the special 6to5 extension is anyway just an intermediate thing, in 1.5 years when node hopefully has harmony i can simply rename the entry point to gulpfile.js back again.

[phated]

@domenic exactly as @geekflyer said (quicker than me at typing 😛). I don't think you should have to name all your files .6to5.js to have them transpiled, as long as your entry point it named that.

[domenic]

Oh, ick, that seems pretty bad. The same concerns about those required subtasks apply as they do to the gulpfile. E.g., you are not writing JS (in the sense of what is interpreted by JS by the node/io.js environment). You are writing the 6to5 dialect, with all its foibles.

[jmm]

@adam-beck That shouldn't be the case. Can you please elaborate on why you say that?

@shadowmint It currently works for me with either babel@5.8.21 or babel-core@5.8.22.

This warning when babel is installed is irrelevant, although I agree it's not ideal for it to be emitted with that being the case (it's just noise that makes the user think something has gone wrong):

Failed to load external module babel-core/register

EDIT: however, in babel v6 the functionality this relies on probably isn't going to be in the babel package, so the best bet is probably to just have babel-core as a local dependency now, as @shadowmint instructed.

[moretti]

babel depends on babel-core, so they don't have to be both installed.
I did some tests in an empty project with a global version of gulp and a local version of babel/babel-core.

Here's my gulpfile:

import gulp from 'gulp';
gulp.task('default', () => console.log('default'));

With babel installed locally:

$ > gulp
[14:16:38] Requiring external module babel/register
[14:16:38] Using gulpfile ~/test/gulpfile.babel.js
[14:16:38] Starting 'default'...
default
[14:16:38] Finished 'default' after 114 μs

With babel-core installed locally:

$ > gulp
[14:17:09] Failed to load external module babel/register
~/test/gulpfile.babel.js:1
(function (exports, require, module, __filename, __dirname) { import gulp from
                                                              ^^^^^^
SyntaxError: Unexpected reserved word

[jmm]

@moretti What's your gulp version? Global gulp@3.9.0 and local babel-core@5.8.22 works for me. It sounds to me like you have a version of the tkellen/js-interpret dep from before this commit: gulpjs/interpret@7d51ead

[moretti]

@jmm I'm using gulp@3.9.0.

~/test> npm list -g --depth=0
/usr/local/lib
├── eslint@1.1.0
├── gulp@3.9.0
├── node-libs-browser@0.5.2
├── npm@2.13.5
├── npm-check-updates@2.2.0
└── webpack@1.11.0

~/test> gulp -v
[14:53:00] Failed to load external module babel/register
[14:53:00] CLI version 3.9.0
[14:53:00] Local version 3.9.0

~/test> ls node_modules
babel-core gulp

~/test> gulp
[14:55:19] Failed to load external module babel/register
~/test/gulpfile.babel.js:1
(function (exports, require, module, __filename, __dirname) { import gulp from

[jmm]

@moretti Try npm ls -g --depth=1 and see what version gulp's interpret dep is at. I'm betting it's <0.6.3.

[moretti]

@jmm Yeah, that's correct, thank you. Removing and reinstalling my global version of gulp fixed the issue.

[jmm]

@moretti Great! You're welcome.

[gravitypersists]

I'm getting an issue related to this, as I'm trying to require the babel/register module from within a gulp task to pass it into the gulp mocha task as a compiler

  const babel = require('babel/register')
  gulp.src('./test/spec/**/*.js')
    .pipe(mocha({compilers: {js: babel}}))

yet I get this error: Error: only one instance of babel/polyfill is allowed

[dead-claudia]

@gravitypersists

1. You require the compilers in the gulpfile itself. That's stated in the gulp-mocha readme itself.
2. Babel, just like CoffeeScript and others, only require you to import the module to register the compiler. Simply require('babel/register') at the top is sufficient.

If Babel is already being used for the gulpfile, all you need is this:

gulp.src('test/spec/**/*.js')
  .pipe(mocha())

If not, you only need this:

require('babel/register')
gulp.src('test/spec/**/*.js')
  .pipe(mocha())

[webdesserts]

is it possible to pass in options when using gulpfile.babel.js named files? Specifically the ignore bit:

require('babel/register')({ ignore: false })

[dead-claudia]

@webdesserts Have you tried using the .babelrc?

[webdesserts]

@IMPinball I did and it would have worked, unfortunately I later found that I also needed to use resolveModuleSource and it doesn't seem like the rc accepts anything more than JSON?

[jmm]

@webdesserts that's my understanding. The idea has crossed my mind of making resolveModuleSource take a string path to a module that exports a function, but it's not a high priority for me, and probably wouldn't be an option before v6 no matter if anyone did the work.

[dead-claudia]

You could also try this as the gulpfile.js:

require('babel/register')({
  /* your extra options */
})
require('./gulpfile.babel.js')

To be honest, this pattern works with any compiler with a require hook.
It's slightly crude, but until Gulp supported Babel, this was my
workaround.

On Sun, Sep 6, 2015, 11:50 Jesse McCarthy notifications@github.com wrote:

@webdesserts https://github.com/webdesserts that's my understanding.
The idea has crossed my mind of making resolveModuleSource take a string
path to a module that exports a function, but it's not a high priority for
me, and probably wouldn't be an option before v6 no matter if anyone did
the work.

—
Reply to this email directly or view it on GitHub
#830 (comment).

[webdesserts]

@IMPinball Yeah, I ended up just doing what I was doing before for now.

https://github.com/webdesserts/alchemist-js/blob/a7df18959bec779c0c4ab917fa21549ec85dc695/gulpfile.js

https://github.com/webdesserts/alchemist-js/blob/a7df18959bec779c0c4ab917fa21549ec85dc695/tasks/babel-setup.js#L1-L13

@jmm It would be nice if babel supported a module.exports = {} config (rather than pointing to a file for one option)

[jmm]

@webdesserts that might be how plugins work in v6, so it might be possible to shift most of the config (or just resolveModuleSource :)) to a plugin and reference that from .babelrc. I don't know if resolveModuleSource will even be a global option anymore though (edit: or if there'll be restrictions on plugins setting global options).

[webdesserts]

@jimm well if you do end up removing resolveModuleSource please make sure there's clean alternative and migration path away from using it. As of right now it's very important to my dev environment.

[jednano]

Those looking for a way to use gulpfile.ts, I've created a gulpfile#typescript branch, which demonstrates a bare minimum example of how it's done.

[dead-claudia]

@jedmao Tip: use typings, not TSD, since the latter is deprecated. Thought I'd catch that early for you. 😉

[jednano]

Thanks @isiahmeadows. I've updated the repo accordingly.

[AndyOGo]

Hy,

Unfortunately, I still have this issue on Windows 10 (Windows_NT 6.3.9600)

I use NVM and run Node version 5.10.1 and NPM version 3.9.5

I have installed gulp and gulp-cli globally and locally as 3.9.0
gulp's interpret dependency has version 0.6.6

I have installed babel-core version 6.9.1 and babel-register version 6.9.0

though I get following errors if I run any gulp command:

Failed to load external module babel-register
Failed to load external module babel-core/register
Failed to load external module babel/register

Hope anyone can help

[jednano]

@AndyOGo I just created a minimal gulpfile repo with 2 branches:

• gulpfile#master
• gulpfile#babel
• gulpfile#typescript

Does the babel branch work for you?