What is gulp.start?

[CWSpear]

I see that gulp.run was deprecated, but I also see that there is a gulp.start command that seems to do the same thing as gulp.run, but just is more aptly named and doesn't come with the deprecation warning.

I couldn't find anything in the docs about gulp.start. Am I correct in thinking that gulp.start is a replacement for gulp.run (because of the better name), or is it some unreliable internal API that some people have stumbled upon and it's gonna disappear someday and people shouldn't rely on it?

If it's just missing from the docs, I'd be willing to do a PR as far as I understand how it works.

[yocontra]

gulp.run had a thing where if you passed it no arguments it would run the default task. This was a stupid wrapper around gulp.start, so gulp.run was deprecated in favor of

1. Using task dependencies
2. Using gulp.start if you absolutely need to

Both of these will be outmoded by the new task system in gulp 4 however, which uses composable functions instead of complex task dependency trees.

[yocontra]

gulp.start is undocumented on purpose because it can lead to complicated build files and we don't want people using it

[CWSpear]

@contra perfect, that answered my question!

The one use-case that comes up a lot is a clean task that clears out the dist folder and that would have to obviously complete before any other start started. But you don't want to make every task depend on the clean task, especially if you were using watchers (you don't want every individual task to run clean before it runs in those cases!).

The two solutions I've been able to come up with to create a clean task that you would run independently, i.e. only via gulp clean, or to use gulp.start, but I didn't particularly care for either of them.

I look forward to what Gulp 4 might bring. Thanks for the information, and for answering so quickly!

[yocontra]

@CWSpear Use run-requence until gulp 4 comes out if you need to do that

[CWSpear]

Awesome, I'll check it out. Thanks again!

[isochronous]

I will say that gulp.start is the only way I've figured out to debug gulp using node-inspector, because adding a gulp.start(taskIWantToDebug) let's me call gulp via node-debug gulpfile.js. If there's a similarly easy way that doesn't rely on gulp.start I'd love to know what it is. Since there's no documented --debug or --debug-brk flags, I'm not sure how else I'd do it.

[yocontra]

@isochronous there is an issue open for passing v8 flags via child_processes, check the issues page (on the phone atm)

[laurelnaiad]

@isochronous: Just yesterday I was in debug mode for a gulp task.. I don't have gulp.start anywhere in my code. I just double checked it and I go straight into debug mode with no complications.

node-debug gulp taskname and it "just works." Are you saying that that isn't working for you?

P.S. Since the title of the issue is "what is gulp.start?" I'll try to answer that one.

gulp#start (n.): a function that people either love or hate, and that either is or isn't necessary for effective use of gulp. See "beauty is in the eye of the beholder" and "to each his own". :wink:

[laurelnaiad]

@isochronous: I wonder if it matters that I have gulp installed globally... if you don't, you might try that.

[akre54]

I always do node --debug $(which gulp) taskname for debugging. Works the same.

[laurelnaiad]

Sounds like a great way to avoid having to install it globally. It was in fact how I checked whether or not I did have it installed globallly -- so just doing $(which gulp) in the command makes perfect sense!

[isochronous]

Honestly I never even thought to try that... facepalm

On May 15, 2014, at 10:40 PM, Stu Salsbury notifications@github.com wrote:

@isochronous: Just yesterday I was in debug mode for a gulp task.. I don't have gulp.start anywhere in my code. I just double checked it and I go straight into debug mode with no complications.

node-debug gulp taskname and it "just works." Are you saying that that isn't working for you?

P.S. Since the title of the issue is "what is gulp.start?" I'll try to answer that one.

gulp#start (n.) A function that people either love or hate, and that either is or isn't necessary for effective use of gulp. See "beauty is in the eye of the beholder" and "to each his own".

— Reply to this email directly or view it on GitHub.

[isochronous]

I will say that node-debug gulp taskname wound up NOT working for me. This is the error I get running node-debug gulp core (a very simple concatenation task). I have gulp installed globally and locally in the directory I'm running it from.

Node Inspector is now available from http://localhost:8080/debug?port=5858
Debugging `gulp`

debugger listening on port 5858

C:\Users\username\AppData\Roaming\npm\gulp.CMD:1
(function (exports, require, module, __filename, __dirname) { @IF EXIST "%~dp0
                                                              ^
SyntaxError: Unexpected token ILLEGAL
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain [as _onTimeout] (module.js:497:10)
    at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

[yocontra]

@isochronous try what @akre54 said

[isochronous]

I'm on a windows box, so the $(which gulp) bit doesn't execute correctly. I could try it from a cygwin bash prompt but I'd rather not rely on cygwin unless I absolutely have to.

[akre54]

@isochronous http://stackoverflow.com/questions/304319/is-there-an-equivalent-of-which-on-the-windows-command-line

[isochronous]

edit: this may be due to a gulp nuget package I just installed. Let me remove it (getting rid of the local gulp.cmd) and try again.

D:\Projects\Launch\ai5\MobileConfig\source\Ai.MobileConfig [GulpTaskRunnerConfig ~5 ?5 !1 tip]> node --debug-brk $(where.exe gulp) core
debugger listening on port 5858

D:\Projects\Launch\ai5\MobileConfig\source\Ai.MobileConfig\gulp.cmd:1
(function (exports, require, module, __filename, __dirname) { @echo off
                                                              ^
SyntaxError: Unexpected token ILLEGAL
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain [as _onTimeout] (module.js:497:10)
    at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

[laurelnaiad]

It looks like you have a windows shell script running. Where does @echo off come from? Is that gulp?

EDIT: sounds like you're on top of it.

[isochronous]

That's what I was saying about the local copy of gulp - that's created by Ncapsulate.Gulp (https://github.com/Blacklite/Ncapsulate). I'm in the middle of something that requires it, but in a few minutes, when I'm done, I'll get rid of it and try it again.

[laurelnaiad]

Never heard of it before.. This is it's reasoning:

Ncapsulate's goal is to surround useful tools like NodeJS, NPM, Bower, Gulp and more while not requiring developers to install the tools or understand how to use their console, and console commands.

This sounds like a really bad idea IMO, but maybe that's just me. These are node tools... why on earth would any sane person put a platform-dependant shell script on top of them and publish it?

[isochronous]

Okay, here's the error after removing the local gulp.cmd file.

D:\Projects\Launch\ai5\MobileConfig\source\Ai.MobileConfig [GulpTaskRunnerConfig !1 tip]> node --debug-brk $(where.exe gulp) core
debugger listening on port 5858

C:\Users\jmcleod\AppData\Roaming\npm\gulp:2
basedir=`dirname "$0"`
        ^
SyntaxError: Unexpected token ILLEGAL
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain [as _onTimeout] (module.js:497:10)
    at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

I really don't want to keep hijacking this thread - if anyone could point me at a better place to take this discussion, I'd be happy to take it to a more appropriate thread.

[laurelnaiad]

Looks like there is still some windows shell scripting getting in your way -- edit or maybe not windows but that sure looks like a shell script.

[isochronous]

@stu-salsbury - because these are tools written in node, but they're certainly not oriented exclusively towards node. I've got five C# developers who know jack diddly about JavaScript who are soon going to be using gulp as a build tool for client-facing scripts. I need the tools to auto-install themselves on any machine on which the projects are opened, and npm install and various gulp tasks need to not only run when those projects are built, but also need to be intelligent enough to integrate properly with msbuild and prevent race conditions from occurring.

As far as windows shell scripting getting in my way, node-debug gulpfile.js works just fine when I use the gulp.start approach I described above, as does node --debug gulpfile.js, as does gulp <taskname>, as does gulp. I think that if my powershell console is somehow getting in the way, then it's probably not unique to my system.

[laurelnaiad]

I won't argue with your decision... I wasn't saying you can't get value from reducing complexity, but IMO hiding the process of installing node is fraught with problems like the one you're experiencing. Once node is installed you can accomplish all of what you want without resorting to platform specific code -- any platform specific code in your process is a risk because the rest of the node world will tend to assume that things are agnostic (such as node-debug).

[isochronous]

While I agree with you in theory, the nuget approach is ideal considering the requirements for this user story. The only person who's going to be adding/updating/removing node modules or debugging tasks will be me or the one other web developer here. For everyone else it'll be an install & forget kinda thing.

[laurelnaiad]

ok, well all that aside you need to convince your environment to let you run node code directly if you want to debug it. Presumably the path of least resistance is specifying the aboslute path to node.

[isochronous]

I'm telling you, the last error I posted has ABSOLUTELY NOTHING TO DO with the nuget package I was talking about. That was run with that package completely uninstalled. The node binary is the normal one on my system path. Gulp was installed locally via npm install gulp as well as globally. Any errors you're seeing are a result of those components. I've been debugging my gulpfile for over a week now by adding gulp.start('taskToDebug') and calling node-debug gulpfile.js. You're trying to solve a problem that doesn't exist.

[laurelnaiad]

Ok, maybe I'm being dense. What language is this:

basedir=`dirname "$0"`

It doesn't look like JS, though I guess it could be, and it doesn't appear in gulp and yet somebody is complaining that it appears on line 2 (I think). Is that node-debug?

[akre54]

@stu-salsbury that's shell script. Wherever it's from it's not portable to Windows. If it's being run from a node module it should be using native modules like path instead.

[laurelnaiad]

Right -- my point is that if it ain't javascript then node-debug will not be able to debug it.

[isochronous]

That's the gulp executable on windows from the regular old npm gulp package. Here's the full thing:

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe"  "%~dp0\..\gulp\bin\gulp.js" %*
) ELSE (
  node  "%~dp0\..\gulp\bin\gulp.js" %*
)

Edit: obviously that isn't the same thing... I was thinking of a previous post. I'm pretty sure I can hunt down where that's coming from though.

[isochronous]

Okay, that's actually coming from the NON-windows gulp executable. Apparently the where.exe command is finding the gulp bash script and executing it instead of the gulp.cmd script. I tried changing it to node --debug $(where.exe gulp.cmd) taskName but still get an error, and this time it actually DOES involve the windows gulp executable:

D:\dev\test\rigger> node --debug-brk $(where.exe gulp.cmd) rig
debugger listening on port 5858

C:\Users\username\AppData\Roaming\npm\gulp.cmd:1
(function (exports, require, module, __filename, __dirname) { @IF EXIST "%~dp0
                                                              ^
SyntaxError: Unexpected token ILLEGAL
    at Module._compile (module.js:439:25)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Module.runMain [as _onTimeout] (module.js:497:10)
    at Timer.listOnTimeout [as ontimeout] (timers.js:110:15)

It looks like $(where.exe gulp.cmd) doesn't like executing windows shell scripts.

[laurelnaiad]

It's node-debug (and underlying that, node itself) that doesn't want to execute anything other than javascript. Each version of your error has been a different script but none of them are javascript. What you see is a node wrapper around non-Javascript code, hence the immediate syntax error.

[isochronous]

I understand that, and I've understood that from the beginning. I was simply asking how to debug a gulp task on windows without needing to use gulp.start. So far every command people have suggested does not work properly on windows. You're correct that the reason they don't work is that there are shell scripts wrapped around the modules I'm trying to debug that are getting in the way. All I've been doing is running the commands people suggest and reporting on whether or not they work. I understand why they're not working, and I didn't really expect them to work - like I said, I'm just looking for an easy way to debug gulp on windows without using gulp.start.

[laurelnaiad]

I will withdraw at this point. It seems like we're communicating at each other, instead of with each other. If you want to solve your issue, I suggest your figure out where that non-Javascript code is originating -- I don't use windows so I don't know how gulp.cmd comes to be -- I don't see it in github.

[isochronous]

I'm pretty sure it's generated by npm on install, because there's a similar file for every globally-installed node module - here's a screenshot of the directory where npm stores those executable versions:

Edit: and they all contain the same format/pattern - Docco:

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe"  "%~dp0\node_modules\docco\bin\docco" %*
) ELSE (
  node  "%~dp0\node_modules\docco\bin\docco" %*
)

Mocha:

@IF EXIST "%~dp0\node.exe" (
  "%~dp0\node.exe"  "%~dp0\node_modules\mocha\bin\mocha" %*
) ELSE (
  node  "%~dp0\node_modules\mocha\bin\mocha" %*
)

etc

[laurelnaiad]

I will then repeat that node-debug should work much better for you if you pass the true gulp file to it instead of gulp.cmd. You could start by specifying the absolute path.

[isochronous]

Yeah, you're right. Like I said, I was just hoping someone knew of a way to avoid that. It's probably faster to just continue using my gulp.start method than to type out the full path to the gulp.js file every time I want to debug.

[laurelnaiad]

you could just set an environment variable for $GULPJS or something or write a .bat file... or do it how you'd like.

[isochronous]

good idea

[avanderhoorn]

Just wondering, in terms of a case for gulp.start how else would you do something like this:

gulp.task('buildwatch', function() {
    watch({ glob: './build/**/*', name: 'WebPack' }, function(files) {
        gulp.start('pack');
    });
});

In short, I only want to execute the pack task when the watch is triggered.

[yocontra]

@avanderhoorn Using gulp.watch: gulp.watch('./build/**/*', ['pack'])

[avanderhoorn]

I'm using gulp-watch because of most of the reasons in the answer here - http://stackoverflow.com/questions/22391527/gulps-gulp-watch-not-triggered-for-new-or-deleted-files. Is this not the case?

On Friday, July 4, 2014, Eric Schoffstall notifications@github.com wrote:

@avanderhoorn https://github.com/avanderhoorn Using gulp core watch: gulp.watch('./build/*/', ['pack'])

— Reply to this email directly or view it on GitHub https://github.com/gulpjs/gulp/issues/426#issuecomment-48063509.

[demisx]

@avanderhoorn You are correct, gulp.watch will only trigger events when existing files are updated. I really don't see any other way of kicking off another gulp task when using gulp-watch. I wonder if anyone else does.

[fesor]

Also wondering how to run tasks by condition. For example i have task index which uses gulp-inject and should re-inject dependencies only if app files was added/removed or bower.json/index.html was changed (as it uses mainBowerFiles, gulp-order and some other heavy logic).

For now i see several options, one of it is to use gulp-cache to increase preformance, but maybe there a better way?

[jednano]

@fesor have you seen/used gulp-if? You can also use the ternary operator with a gutil.noop() on a false condition.

[fesor]

Yes, i seen it and use it. But i need to skip whole task, not just one step. This is simple example of behavior that i want to achieve:

var skipIndex = false;

gulp.task('index', function (done) {
    if (skipIndex) {
        return done();
    }

    return gulp.src('src/index.html')
        // will inject every *.js file of my app, all bower deps, 
        // uses gulp-order to reorder files basing on their dependencies and so on
        .pipe(inject(scripts()) 
        .pipe(rename({extname: '_dev.html'}))
        .pipe(gulp.dest('src/'));
});

gulp.task('server', function () {
    gulp.watch(['src/index.html', 'bower.json'], ['index']);
    gulp.watch(someGlob, ['index']).on('change', function (e) {
        skipIndex = e.type !== 'added' && e.type !== 'deleted';
    });
});

I don't think that this is good solution.

[jednano]

@fesor couldn't the same be achieved with this?

var skipIndex = false;

gulp.task('server', function () {

    // do things

    if (skipIndex) {
        return;
    }

    gulp.watch(['src/index.html', 'bower.json'], ['index']);
    gulp.watch(someGlob, ['index']).on('change', function (e) {
        skipIndex = e.type !== 'added' && e.type !== 'deleted';
    });
});

You could also think of it like this:

var skipIndex = false;

gulp.task('server', function () {

    // do things

    if (!skipIndex) {
        gulp.watch(['src/index.html', 'bower.json'], ['index']);
        gulp.watch(someGlob, ['index']).on('change', function (e) {
            skipIndex = e.type !== 'added' && e.type !== 'deleted';
        });
    }

    // do more things
});

Or is your scenario more complicated than what you posted? I definitely see what you're trying to do though.

[fesor]

Condition in your example is pointless since it always executes only one time and always be true. I just want prevent execution of some task when files are changed and allow task to do it's work in case deletion/addition of files.

[jednano]

@fesor you are right. Wasn't thinkin' straight. I wish I could think of a better way to accomplish your goal with existing syntax, but I think the way you're doing it is actually pretty nice. Still, it'd be nice to have syntax something like this:

gulp.task('server', function () {
    var skipIndex = false;
    function index() {
        return (skipIndex) ? [] : ['index'];
    }
    gulp.watch(['src/index.html', 'bower.json'], index);
    gulp.watch(someGlob, index).on('change', function (e) {
        skipIndex = e.type !== 'added' && e.type !== 'deleted';
    });
});

This way, at least, the skipIndex logic is contained within the server task.