Gulp: Support ES6

[phated]

This work has been discussed and issue opened over at https://github.com/tkellen/node-interpret/issues/8

[sindresorhus]

:+1: 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]

:+1: 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 https://github.com/gulpjs/gulp/commit/c1cf3cbec3ece0652833f800ab26281384da0489 :wink:

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

:+1:

[geekflyer]

:+1: 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 :stuck_out_tongue:). 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.

[phated]

@domenic That's a pretty crazy claim, as you were pushing traceur's require system not so long ago and they hijack all of the built in node extensions

[domenic]

Sure, when you explicitly opt-in by using a different executable (e.g. traceur-runner or traceur itself). Not just as a default for your entire Node/IO environment.

[phated]

You are opting in by making your gulpfile gulpfile.6to5.js. Do we have a disconnect?

[geekflyer]

It's just hooking in when you start gulp via an gulpfile.6to5.js entrypoint - I think that's explicit enough.

[domenic]

I guess you could see that as an opt-in, but it's a pretty implicit one, disconnected from the actual act of running the file. Maybe it's enough though.

As another example, I currently opt in to ES6 transpilation in my Gulpfile by running a separate gulpur executable. Similarly to how I opt-in to ES6 transpilation for my pure Node scripts by running the separate traceur-runner executable.

Choosing a different executable seems like a clearer opt-in than naming some file on disk with a different extension, no matter how important that file is.

[phated]

@domenic but you seem to be missing the fact that gulp does this for a huge variety of extensions already, everything in https://github.com/tkellen/node-interpret#jsvariants

[domenic]

Yeah, but none of those change how normal JavaScript in a .js file is interpreted. Those are all processed with the built-in V8 of Node or IO.

[phated]

That is up to the implementation. If coffee-script started registering on the .js extension, it would be parsed by coffee-script. We can't control the world.

[geekflyer]

@domenic Do you have a code example how you spawn a seperate gulpur executable?
Just have the concern that spawning a subprocess often leads to weird behaviour when you run some tasks there.

[domenic]

@geekflyer https://github.com/domenic/html-as-custom-elements/blob/master/package.json#L8-L13

[phated]

I'd actually like to support traceur and 6to5 within node-interpret and with the .6to5.js change, we could do .traceur.js also. They both would be opt-ins to register on their extension but would hook into the .js extension if loaded.

[phated]

gulpur being in userland is very scary to me because I then have to be worried about breaking the CLI (note how he doesn't even check package.json's bin file)

[geekflyer]

In summary I feel, loading Traceur or 6to5 using gulpfile.traceur.js or gulpfile.6to5.js and transpiling all the other .js files is fine and should be the default - it covers probably the needs of >80% of users and is simply the most convenient.
I don't want to rename all my files to .6to5.js for opting in. Just think of the case that I just want to give traceur a try - renaming all files would be a mess. Just have to rename a single gulpfile is OK.
Having some files transpiled with traceur and some others with 6to5 probably also doesn't make sense, so deriving the config from a central entrypoint file extension is ok.

In any case, if someone needs more control, he could simply write a normal entrypoint gulpfile.js in which he loads loads the require hook and configure it in detail as described here: https://6to5.org/docs/usage/require/ . Then after you loaded the require hook you can require your actual gulpfile with whatever name / extension it has.
This approach is described here (using TypeScript require hook): http://dinozafirakos.com/2014/06/30/typescript-and-gulp/

[contra]

I'm :+1: on all files that want to be transpiled with 6to5 having to end with .6to5.js for consistency with existing transpilers and because it seems more sane.

[gsklee]

[17:37:25] Failed to load external module 6to5/register

Can we change that to babel/register? Also, should be able to detect gulpfile.babel.js.

[phated]

@gsklee I want to get this in/done before we bump from the updated interpret since it would be a breaking change if we had already published it

[phated]

we should also try to get the updates to liftoff implemented so we can configure the correct extensions

[phated]

@contra @geekflyer @domenic it seems that node uses path.extname internally which causes .babel.js to result in just the .js extension. Thoughts?

[phated]

We are going to implement the solution described in https://github.com/gulpjs/gulp/issues/830#issuecomment-69513187 as it will work in node's very limited system and the user chose to run in that environment.

[jirutka]

IMHO much better solution is to use a “magic comment” on top of the file as proposed @theefer. It’s a commonly used pattern, for example:

• encoding in Ruby, e.g. # encoding: utf-8
• encoding in Python, e.g. # coding: utf-8
• Shebang in Unix, e.g. #!/bin/sh
• modelines in vim, e.g. # vim: set ts=4

It’s more scalable and cleaner.

[gsklee]

@jirutka We don't need any non-standard, invented "magic" comment. There's already a standard-friendly solution in the v4 branch but slightly outdated (due to the 6to5 -> babel renaming) and we're just discussing about updating relevant parts.

[phated]

This is already implemented in the 4.0 branch of gulp-cli and has even been updated for babel

[phated]

This should be fixed in the just published v3.9.0 - much :heart: for @tkellen for making the backport-able

[ai]

So, what we need to do to use ES6 in Gulpfile? I can’t find a docs.

[lukehorvat]

@ai Rename gulpfile.js to gulpfile.babel.js and include Babel as a dependency in package.json.

[sindresorhus]

Example: https://github.com/google/web-starter-kit/pull/710/files

[sashasochka]

Looks like this doesn't work when gulpfile path is specified for gulp directly. (At least doesn't work in Intellij Idea gulp plugin).

[callumacrae]

Sounds like an issue you should take up with JetBrains

[sashasochka]

Already submitted there, but seems like gulp should also be able to recognize that filename is gulpfile.babel.js even if passed through command line path option.

[phated]

@sochka can you please open this as a new issue with more details (you could also link to the intellij issue) instead of posting "it doesn't work" here. This will allow us to actually investigate the potential issue.

[sashasochka]

Sorry, I was actually wrong - the problem is only with Intellij idea's gulp plugin; manually checked --gulpfile option and gulp works correctly.

[phated]

@sochka i think intellij might bundle a version of gulp, so maybe it is just out of date

[phated]

@sochka thanks for digging in some more

[sashasochka]

Nope, you have to specify gulp package path in idea's settings.

[shadowmint]

For others finding this thread, once again to reiterate:

To use an es6 gulpfile you must:

• Be running gulp (global install) version 3.9.0+
• Call your gulpfile gulpfile.babel.js
• Install babel locally, using: npm install --save-dev babel-core

If any of these are not met you will get errors or warnings. Installed babel, or gulp-babel is not sufficient.

Since the 4.0 branch isn't going to be released anytime very soon, it's probably worth actually documenting this somewhere in the wiki.

[nirazul]

I hope this is clear to anyone reading this, but just to prevent copy-paste errors: Your gulpfile needs to be called gulpfile.babel.js, not bulpfile.

[moretti]

@shadowmint Looks like you have to install locally babel rather than babel-core.
I tried with only babel-core and I got the following error:
[12:29:29] Failed to load external module babel/register

[adam-beck]

@moretti both babel and babel-core must be installed

[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 [email protected] or [email protected].

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:

``` .js
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 [email protected] and local [email protected] works for me. It sounds to me like you have a version of the tkellen/js-interpret dep from before this commit: https://github.com/tkellen/js-interpret/commit/7d51ead4d9038d5cc378fd95d309b41f2eb07852

[moretti]

@jmm I'm using [email protected].

~/test> npm list -g --depth=0
/usr/local/lib
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
├── [email protected]
└── [email protected]

~/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

[isiahmeadows]

@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 })

[isiahmeadows]

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

[isiahmeadows]

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 [email protected] 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
https://github.com/gulpjs/gulp/issues/830#issuecomment-138094561.

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

[jedmao]

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.

[isiahmeadows]

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

[jedmao]

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

[jedmao]

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

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

Does the babel branch work for you?