Some kind of silent abort functionality

[rhendric]

Moving discussion here from gulpjs/gulp#1535.

I'm going to try to start from the beginning; I fear there've been more misunderstandings than effective communication on my part in the previous thread, and I want to lay all of my logic out in order hopefully to avoid more of the same. So, sorry this is a little long and somewhat redundant.

This started because I wanted a way to automatically restart gulp with extra Node.js flags, instead of requiring that the end user always remember to type gulp --harmony_proxies. As long as the status quo is maintained, I don't expect very many people to be able to take advantage of bleeding-edge Node.js features in gulpfiles or gulp plugins, due to the burden that would impose of always having to add the flags to the command line. Almost anything would be an improvement: a package.json option, a new .gulpflags file, a pragma at the beginning of gulpfiles, anything where the intent to use flags can be stored with the code rather than supplied by the end user at every call.

I figured, however, that the most gulpish approach—and better by far than any of the above—would be regular JavaScript code, some kind of requireNodeFlags('--harmony_proxies') that could be called and, if done before any tasks started executing, would trigger a respawn of gulp with any flags that were missing from process.execArgv. Inspired by the respawn code gulp already uses (via liftoff) to respawn itself when such flags are provided on the gulp command line, I attempted to write this function as a module. The respawning worked, but the original gulp would continue as well. Returning early from the gulpfile just results in a noisy ‘missing task’ error being dumped. Throwing an error is equally noisy. Calling process.exit dumps the user back to the command prompt while the respawned gulp continues in the background—not the desired effect. Short of some really egregious monkey patching, there didn't seem to be a way to silently abort the original gulp execution but not the entire process without changes to gulp.

My original PR had a bunch of mistakes; I tried to package the entire feature up in one place rather than try to introduce the minimal amount of code necessary for me to achieve the rest of what I want in my own module. The bare minimum that I need is some way to silently abort gulp without an actual process.exit. This capability needs to be available when the gulpfile is being evaluated, but it's fine if it's unavailable once a task starts to execute (probably better that way, in fact). The most expedient way to get this that I can think of is to wrap the require(env.configPath) call with a try/catch, where the catch checks for something on the error caught that indicates it's a silent-abort signal, and returns from the main function in that case. (Note: I've tested this with gulp 3.9, but not with gulp 4.0/gulp-cli; from a cursory glance at the code it looks like this will still work fine but I'll want to test once I figure out how this brave new gulp works.) I'm entirely open to other ways to deliver this capability that don't involve magical errors, though all the alternatives I can think of at the moment seem somewhat inferior.

Although I would be completely happy if the above is all that gets implemented in gulp projects, there is an argument for putting some additional code in (probably? so that plugins can call it too, not just gulpfiles?) gulp-utils to create errors that meet the silent-abort condition, whatever that may be. The argument is that it's a little weird for some lines of error-handling code inside gulp-cli to be coupled to the requireNodeFlags module I'm going to write, which has no affiliation with gulp; but it'd be considerably less weird for that code to be coupled to either an Error subclass, or a function that throws such an error, that's exposed in gulp-util and that other modules like mine can use. But again, this is just a suggestion for you to take or leave; I'm happy to help with implementation, tests, and documentation if this is what you want, and just as happy to let it go if it isn't.

Finally, if you accept the idea of adding the abort capability to gulp-cli, and if you also decide to add the API for exposing that capability through gulp-utils (or any other official gulp project), then you have the question of whether to expose the more general capability of ‘silent abort’ or the more bounded capability of ‘restart with new flags’. Once again, I'm happy either way; I think it just comes down to your preference for maintaining code that could have many applications (and thus is harder to design away from, once released) or that serves a specific need (and thus can be reimplemented more freely as things change). I assumed, as an established project with a ton of users, that you'd be more inclined towards the latter scenario, which is why I proposed giving the whole feature to you since at the end of the day, it's maybe ten more lines of code to do it that way (not counting the tests I haven't written yet). But, as above, I'm fine with whatever you decide about this!

Thanks for reading, and sorry if I'm being a nuisance about this; I'm just trying to do my part to help make a great project even better. 😁