Support ES6 #830

Closed
phated opened this Issue Dec 16, 2014 · 84 comments

Comments

Projects
None yet
@phated
Member

phated commented Dec 16, 2014

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

@sindresorhus

This comment has been minimized.

Show comment
Hide comment
@sindresorhus

sindresorhus Dec 17, 2014

Contributor

👍 Would be awesome to have this work transparently.

Contributor

sindresorhus commented Dec 17, 2014

👍 Would be awesome to have this work transparently.

@sindresorhus sindresorhus changed the title from Support es6 to Support ES6 Dec 17, 2014

@domenic

This comment has been minimized.

Show comment
Hide comment
@phated

This comment has been minimized.

Show comment
Hide comment
@phated

phated Dec 18, 2014

Member

@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

Member

phated commented Dec 18, 2014

@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

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 10, 2015

Contributor

👍 looking forward for it.

Contributor

geekflyer commented Jan 10, 2015

👍 looking forward for it.

phated added a commit to gulpjs/gulp-cli that referenced this issue Jan 10, 2015

@phated

This comment has been minimized.

Show comment
Hide comment
@phated

phated Jan 10, 2015

Member

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

Member

phated commented Jan 10, 2015

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

@geekflyer

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 10, 2015

Contributor

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

Contributor

geekflyer commented Jan 10, 2015

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

@phated

This comment has been minimized.

Show comment
Hide comment
Member

phated commented Jan 11, 2015

@geekflyer

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 11, 2015

Contributor

@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". :-)

Contributor

geekflyer commented Jan 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 11, 2015

Contributor

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

Contributor

geekflyer commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@phated

phated Jan 11, 2015

Member

Should be working now. Thanks for catching those.

Member

phated commented Jan 11, 2015

Should be working now. Thanks for catching those.

@geekflyer

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 11, 2015

Contributor

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

Contributor

geekflyer commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@ilanbiala

ilanbiala Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 11, 2015

Contributor

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

Contributor

geekflyer commented Jan 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 11, 2015

Contributor

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

Contributor

geekflyer commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@theefer

theefer Jan 11, 2015

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.

theefer commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 11, 2015

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

domenic commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@sindresorhus

sindresorhus Jan 11, 2015

Contributor

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.

👍

Contributor

sindresorhus commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 11, 2015

Contributor

👍 for .6to5.js

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

Contributor

geekflyer commented Jan 11, 2015

👍 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

This comment has been minimized.

Show comment
Hide comment
@arthurvr

arthurvr Jan 11, 2015

I'm +1 for .6to5.js

I'm +1 for .6to5.js

@phated

This comment has been minimized.

Show comment
Hide comment
@phated

phated Jan 11, 2015

Member

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.

Member

phated commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 11, 2015

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?

domenic commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 11, 2015

Contributor

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

Contributor

geekflyer commented Jan 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@phated

phated Jan 11, 2015

Member

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

Member

phated commented Jan 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 11, 2015

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.

domenic commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@phated

phated Jan 11, 2015

Member

@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

Member

phated commented Jan 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 11, 2015

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.

domenic commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@phated

phated Jan 11, 2015

Member

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

Member

phated commented Jan 11, 2015

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

@geekflyer

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 11, 2015

Contributor

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

Contributor

geekflyer commented Jan 11, 2015

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

@domenic

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 11, 2015

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.

domenic commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@phated

phated Jan 11, 2015

Member

@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

Member

phated commented Jan 11, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@domenic

domenic Jan 11, 2015

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.

domenic commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@phated

phated Jan 11, 2015

Member

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.

Member

phated commented Jan 11, 2015

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

This comment has been minimized.

Show comment
Hide comment
@geekflyer

geekflyer Jan 11, 2015

Contributor

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

Contributor

geekflyer commented Jan 11, 2015

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

@phated

This comment has been minimized.

Show comment
Hide comment
@phated

phated Jun 9, 2015

Member

@sochka thanks for digging in some more

Member

phated commented Jun 9, 2015

@sochka thanks for digging in some more

@sochka

This comment has been minimized.

Show comment
Hide comment
@sochka

sochka Jun 9, 2015

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

sochka commented Jun 9, 2015

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

@ghost ghost referenced this issue in ctf0/Seti_ST3 Jun 13, 2015

Merged

Add support to detect gulpfile.babel.js #146

@shadowmint

This comment has been minimized.

Show comment
Hide comment
@shadowmint

shadowmint Jul 22, 2015

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.

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

This comment has been minimized.

Show comment
Hide comment
@nirazul

nirazul Jul 22, 2015

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.

nirazul commented Jul 22, 2015

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

This comment has been minimized.

Show comment
Hide comment
@moretti

moretti Jul 27, 2015

@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

moretti commented Jul 27, 2015

@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

@phated phated referenced this issue in sintaxi/terraform Jul 28, 2015

Open

added ES6 support with babel #82

@stoeffel stoeffel referenced this issue in stoeffel/gulp-param Aug 7, 2015

Closed

Does this work with ES6? #5

@adam-beck

This comment has been minimized.

Show comment
Hide comment
@adam-beck

adam-beck Aug 14, 2015

@moretti both babel and babel-core must be installed

@moretti both babel and babel-core must be installed

@jmm

This comment has been minimized.

Show comment
Hide comment
@jmm

jmm Aug 14, 2015

Contributor

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

Contributor

jmm commented Aug 14, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@moretti

moretti Aug 14, 2015

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

moretti commented Aug 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@jmm

jmm Aug 14, 2015

Contributor

@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

Contributor

jmm commented Aug 14, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@moretti

moretti Aug 14, 2015

@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

moretti commented Aug 14, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@jmm

jmm Aug 14, 2015

Contributor

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

Contributor

jmm commented Aug 14, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@moretti

moretti Aug 14, 2015

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

moretti commented Aug 14, 2015

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

@jmm

This comment has been minimized.

Show comment
Hide comment
@jmm

jmm Aug 14, 2015

Contributor

@moretti Great! You're welcome.

Contributor

jmm commented Aug 14, 2015

@moretti Great! You're welcome.

@gravitypersists

This comment has been minimized.

Show comment
Hide comment
@gravitypersists

gravitypersists Aug 27, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@isiahmeadows

isiahmeadows Aug 29, 2015

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

@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

This comment has been minimized.

Show comment
Hide comment
@webdesserts

webdesserts Sep 6, 2015

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

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

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

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

This comment has been minimized.

Show comment
Hide comment
@isiahmeadows

isiahmeadows Sep 6, 2015

@webdesserts Have you tried using the .babelrc?

@webdesserts Have you tried using the .babelrc?

@webdesserts

This comment has been minimized.

Show comment
Hide comment
@webdesserts

webdesserts Sep 6, 2015

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

@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

This comment has been minimized.

Show comment
Hide comment
@jmm

jmm Sep 6, 2015

Contributor

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

Contributor

jmm commented Sep 6, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@isiahmeadows

isiahmeadows Sep 6, 2015

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

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

This comment has been minimized.

Show comment
Hide comment
@webdesserts

webdesserts Sep 6, 2015

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

@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

This comment has been minimized.

Show comment
Hide comment
@jmm

jmm Sep 7, 2015

Contributor

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

Contributor

jmm commented Sep 7, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@webdesserts

webdesserts Sep 8, 2015

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

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

@jmm jmm referenced this issue in jamesplease/testing-with-babel Dec 31, 2015

Open

Investigate `register-babel` necessity #5

@jedmao jedmao referenced this issue in TypeStrong/ts-node Feb 2, 2016

Closed

Add documentation on Gulp usage #26

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Feb 3, 2016

Contributor

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.

Contributor

jedmao commented Feb 3, 2016

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

This comment has been minimized.

Show comment
Hide comment
@isiahmeadows

isiahmeadows Feb 4, 2016

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

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

@jedmao

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Feb 4, 2016

Contributor

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

Contributor

jedmao commented Feb 4, 2016

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

@AndyOGo

This comment has been minimized.

Show comment
Hide comment
@AndyOGo

AndyOGo Jun 10, 2016

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

AndyOGo commented Jun 10, 2016

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

This comment has been minimized.

Show comment
Hide comment
@jedmao

jedmao Jun 10, 2016

Contributor

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

Does the babel branch work for you?

Contributor

jedmao commented Jun 10, 2016

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

Does the babel branch work for you?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment