gulpjs / gulp-cli Goto Github PK

Would love to have a legit change log. I'll even attach to each version in "Releases". Anyone want to take a stab based on the commits?

The flags should be able to be defaulted in the .gulprc file so people can rely on gulpfiles running in a certain way. e.g. running with a certain log level

The CLI options aren't currently documented, and it's not clear, even when looking at the source, what the options are.

Here's when I run dev task with continue flag
Seems like it just log that error on every dependent task.

[02:37:26] Using gulpfile D:\_host\github\case\gulpfile.js
[02:37:26] Starting 'dev'...
[02:37:26] Starting 'watch'...
[02:37:26] Finished 'watch' after 12 ms
[02:37:26] Starting 'server'...
[02:37:26] Started server on http://localhost:8080
[02:37:26] Finished 'server' after 62 ms
[02:37:26] Starting 'build'...
[02:37:26] Starting 'clean (skipped)'...
[02:37:26] Finished 'clean (skipped)' after 3.61 ms
[02:37:26] Starting '<parallel>'...
[02:37:26] Starting 'markup'...
[02:37:26] Starting 'script'...
[02:37:26] Starting 'style'...
[02:37:26] Starting 'image'...
[02:37:27] Finished 'image' after 1.21 s
[02:37:27] Finished 'script' after 1.23 s
[02:37:27] 'markup' errored after 1.23 s
[02:37:27] Error in plugin 'gulp-file-include'
Message:
    ENOENT, no such file or directory 'D:\_host\github\case\app\markup\sss'
Details:
    domainEmitter: [object Object]
    domain: [object Object]
    domainThrown: false
[02:37:27] Finished 'style' after 1.27 s
[02:37:27] '<parallel>' errored after 1.28 s
[02:37:27] 'build' errored after 1.3 s
[02:37:27] Error: Error in plugin 'gulp-file-include'
Message:
    ENOENT, no such file or directory 'D:\_host\github\case\app\markup\sss'
Details:
    domainEmitter: [object Object]
    domain: [object Object]
    domainThrown: false
    at formatError (D:\_station\nvm\v0.12.7\node_modules\gulp-cli\lib\versioned\^4.0.0\formatError.js:20:10)
    at Gulp.<anonymous> (D:\_station\nvm\v0.12.7\node_modules\gulp-cli\lib\versioned\^4.0.0\log\events.js:30:15)
    at Gulp.emit (events.js:129:20)
    at Object.error (D:\_host\github\case\node_modules\undertaker\lib\helpers\createExtensions.js:58:10)
    at Object.after (D:\_host\github\case\node_modules\undertaker\lib\helpers\createExtensions.js:43:21)
    at handler (D:\_host\github\case\node_modules\now-and-later\lib\mapSeries.js:47:12)
    at f (D:\_host\github\case\node_modules\once\once.js:17:25)
    at D:\_host\github\case\node_modules\async-settle\index.js:17:5
    at f (D:\_host\github\case\node_modules\once\once.js:17:25)
    at done (D:\_host\github\case\node_modules\async-settle\node_modules\async-done\index.js:26:12)
[02:37:27] 'dev' errored after 1.38 s
[02:37:27] Error: Error in plugin 'gulp-file-include'
Message:
    ENOENT, no such file or directory 'D:\_host\github\case\app\markup\sss'
Details:
    domainEmitter: [object Object]
    domain: [object Object]
    domainThrown: false
    at formatError (D:\_station\nvm\v0.12.7\node_modules\gulp-cli\lib\versioned\^4.0.0\formatError.js:20:10)
    at Gulp.<anonymous> (D:\_station\nvm\v0.12.7\node_modules\gulp-cli\lib\versioned\^4.0.0\log\events.js:30:15)
    at Gulp.emit (events.js:129:20)
    at Object.error (D:\_host\github\case\node_modules\undertaker\lib\helpers\createExtensions.js:58:10)
    at Object.after (D:\_host\github\case\node_modules\undertaker\lib\helpers\createExtensions.js:43:21)
    at handler (D:\_host\github\case\node_modules\now-and-later\lib\map.js:50:12)
    at f (D:\_host\github\case\node_modules\once\once.js:17:25)
    at D:\_host\github\case\node_modules\async-settle\index.js:17:5
    at f (D:\_host\github\case\node_modules\once\once.js:17:25)
    at done (D:\_host\github\case\node_modules\async-settle\node_modules\async-done\index.js:26:12)

This request came out of this discussion: chmontgomery/gulp-help#19

In gulp4 it would be nice to allow documenting task flags. I am already making this possible via gulp-help, along with a few other features as seen here:

The suggestion was brought up to possibly add this feature to gulp core. I'd be willing to help with a PR but I'm curious what your thoughts are on doing this and how best to design it.

Also, I think neither current task view (--tasks or --tasks-simple) displays in a way conducive to showing task flags. I'd suggest a new flag, perhaps --tasks-pretty that looks closer to what I have above?

Hey,

i just did a fresh install of gulp-cli and gulp, bothfrom branch#4 and unfortunately it's broken. The scripts worked before, now i get the following error

/usr/lib/node_modules/gulp-cli/lib/versioned/^4.0.0-alpha.1/index.js:34
        return gulpInst.get(task).description;
                        ^
TypeError: undefined is not a function
    at /usr/lib/node_modules/gulp-cli/lib/versioned/^4.0.0-alpha.1/index.js:34:25
    at /usr/lib/node_modules/gulp-cli/lib/shared/log/tasks.js:37:10
    at Array.forEach (native)
    at logTasks (/usr/lib/node_modules/gulp-cli/lib/shared/log/tasks.js:23:8)
    at /usr/lib/node_modules/gulp-cli/lib/versioned/^4.0.0-alpha.1/index.js:33:14
    at process._tickCallback (node.js:355:11)
    at Function.Module.runMain (module.js:503:11)
    at startup (node.js:129:16)
    at node.js:814:3

with

[email protected]
[email protected]

Cheers!

Hey, locally I have modified the coveralls script to be lab -r lcov >> lcov.info just to see the coverage that it produces and everytime I see this error:

assert.js:89
  throw new assert.AssertionError({
  ^
AssertionError: Task function must be specified
    at Gulp.set [as _setTask] (/Users/erikdonohoo/dev/personal/gulp-cli/node_modules/undertaker/lib/set-task.js:12:3)
    at Gulp.task (/Users/erikdonohoo/dev/personal/gulp-cli/node_modules/undertaker/lib/task.js:13:8)
    at Object.<anonymous> (/Users/erikdonohoo/dev/personal/gulp-cli/test/fixtures/gulpfile-3.8.10.js:9:6)
    at Module._compile (module.js:398:26)
    at Object.require.extensions.(anonymous function) [as .js] (/Users/erikdonohoo/dev/personal/gulp-cli/node_modules/lab/lib/coverage.js:34:28)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Module.require (module.js:354:17)
    at require (internal/module.js:12:17)
    at /Users/erikdonohoo/dev/personal/gulp-cli/node_modules/lab/lib/cli.js:104:23
    at Array.forEach (native)
    at Object.internals.traverse (/Users/erikdonohoo/dev/personal/gulp-cli/node_modules/lab/lib/cli.js:100:19)
    at Object.exports.run (/Users/erikdonohoo/dev/personal/gulp-cli/node_modules/lab/lib/cli.js:49:29)
    at Object.<anonymous> (/Users/erikdonohoo/dev/personal/gulp-cli/node_modules/lab/bin/lab:3:23)
    at Module._compile (module.js:398:26)
    at Object.Module._extensions..js (module.js:405:10)
    at Module.load (module.js:344:32)
    at Function.Module._load (module.js:301:12)
    at Function.Module.runMain (module.js:430:10)
    at startup (node.js:141:18)
    at node.js:980:3

npm ERR! Darwin 15.2.0
npm ERR! argv "/Users/erikdonohoo/.nvm/versions/node/v5.3.0/bin/node" "/Users/erikdonohoo/.nvm/versions/node/v5.3.0/bin/npm" "run" "coveralls"
npm ERR! node v5.3.0
npm ERR! npm  v3.3.12
npm ERR! code ELIFECYCLE
npm ERR! gulp-cli@1.1.0 coveralls: `lab -r lcov >> lcov.info`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the gulp-cli@1.1.0 coveralls script 'lab -r lcov >> lcov.info'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the gulp-cli package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     lab -r lcov >> lcov.info
npm ERR! You can get their info via:
npm ERR!     npm owner ls gulp-cli
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/erikdonohoo/dev/personal/gulp-cli/npm-debug.log

Is there something I am missing here? I am looking at your code as an example of how to test a node CLI tool. I'm reading up and lab and code but do you have any ideas just by looking at this? I am using nvm on my machine for my node install. It seems like lab is trying to cover files it shouldn't. Is there a way to tell lab which files are meant to be run?

no breaking changes, just recognizing the project has reached 1.0 maturity (v8flags hasn't yet, though!).

2.0 will bring support for locating multiple config files (like .gulprc for example).

gulp-cli is going to be installed only as a devDependency or as a global module. It would make sense to optimise the installation time. Consider using https://docs.npmjs.com/files/package.json#bundleddependencies or https://github.com/gajus/bundle-dependencies. Either would cut-off a lot of time from the install.

Sorry for opening an issue for such a question. Which is the ETA for gulp-cli 4.0 (the version that is supposed to run any local gulp version)?

It would be nice if gulp-cli/readme will contain reference to completion readme

Might be useful for everyone.

Does it really matter which branch of gulp-cli do I use with gulpjs/gulp#4.0 ?

4.0 branch has version number 0.4.0 and libs for gulp 4.0 alpha 1 and 2
master branch has version number 1.1.0 and libs for gulp 4.0 alpha 1, 2 and release.

Is branch 4.0 redundant now?

Currently, when people don't have a local gulp installed, they are seeing errors such as #33

I'd really like to have a better check around local gulp install and a nice error message.

@tkellen is there a way for us to do this using the object Liftoff gives us?

If we see a property named description on a task function, we should print it when using the --tasks flag.

ref gulpjs/gulp#591

Since switching to gulp-cli, I've noticed that the --tasks-json switch no longer works on projects that use 3.9.x versions of gulp.

Expected result

Running gulp --tasks-json outputs a list of the tasks in JSON format.

Observed result

Running gulp --tasks-json just starts the default tasks (as if the --tasks-json was not there)

Steps to reproduce

1. Install gulp-cli on your system (I'm using version 1.2.1).
2. Navigate to the root of a project that has a Gulp 3.9.1 release locally installed
3. Run gulp --tasks-json

Additional notes

This has the unfortunate effect of breaking the WebStorm IDE's Gulp tool window (which appears to use that switch to get a list of tasks). :-(

I've peaked at the gulp-cli code and noticed that the lib/versioned/^3.7.0/index.js does not appear to check for the opts.tasksJson inside process.nextTick(), whereas the corresponding lib/versioned/^4.0.0/index.js does.

Perhaps it's a simple omission and the code to enable the --tasks-json needs to be added to the ^3.7.0 file?

I've added customizing mechanism in gulp-cli.
And also I've made colors of a task tree customizable with this.

sttk/gulp-cli#make_customizable

• You can change the colors by .gulprc files in user home directory or project working directory.
• You can also change the colors with a file specified by --customize option.
• You can see a list of customizable settings by --customize option which has no value.

I have the following entry in my package.json file
"gulp": "github:gulpjs/gulp#4.0"

i ran npm install -g "#4.0" and it gives me and error fatal: ambiguous argument '4.0': unknown revision or path not in the working tree.

Here is the error I get when I run gulp
**gulp
[02:49:31] Using gulpfile ~/Documents/XXXX/gulpfile.js
/usr/local/lib/node_modules/gulp/bin/gulp.js:129
gulpInst.start.apply(gulpInst, toRun);
^

TypeError: Cannot read property 'apply' of undefined
at /usr/local/lib/node_modules/gulp/bin/gulp.js:129:19
at _combinedTickCallback (internal/process/next_tick.js:67:7)
at process._tickCallback (internal/process/next_tick.js:98:9)
at Function.Module.runMain (module.js:577:11)
at startup (node.js:160:18)
at node.js:449:3**

Also The Output for gulp -v
gulp -v [02:55:57] CLI version 3.9.1
[02:55:57] Local version 4.0.0-alpha.2

Implement through use of gulpjs/liftoff#8 which has outstanding PR at gulpjs/liftoff#67

Building a tool with separate core and cli, I was looking at gulp and gulp-cli (4.0 branches) for an example. I noticed that gulp-cli/index.js has a shebang line and executable mode, but I can't figure out why...

The script exports a function, running it with ./index.js doesn't really do anything, it seems to me. Is there something clever going on here, or is this maybe a leftover of an earlier setup? It looks like it would have made sense before these:

gulpjs/gulp@95ce47a

6b2c2ef

I was also wondering why gulp has its own executable bin/gulp.js, which just requires gulp-cli and runs the exported function -- but now I suspect that this is in case users do npm install -g gulp (instead of installing only gulp-cli globally as recommended in the getting started guide). Have I got that right?

While there are a couple of workarounds for this floating around (see @tilap's example) having this feature baked in and accessible via flag would be pretty sweet.

Within my project's package.json I have:

json
"dependencies": {
  "gulp": "git+https://github.com/gulpjs/gulp.git#4.0"
}

If I globally install stable gulp (3.X) and run gulp it fails (known issue, ok). But if I globally install gulp-cli it also fails:

bash
$ gulp
[15:59:34] Using gulpfile ~/src/XXX/gulpfile.js

/Users/xxxxxx/.npm-packages/lib/node_modules/gulp-cli/index.js:133
    gulpInst.start.apply(gulpInst, toRun);
                   ^
TypeError: Cannot call method 'apply' of undefined
    at /Users/xxxxxx/.npm-packages/lib/node_modules/gulp-cli/index.js:133:20
    at process._tickDomainCallback (node.js:463:13)
    at Function.Module.runMain (module.js:499:11)
    at startup (node.js:119:16)
    at node.js:906:3

I fail to understand the purpose of gulp-cli if it fails in this scenario. Do I miss something?

gulp autocompletion rules for 'bash' not found with eval "$(gulp --completion=bash)" in the bashrc which is what we used to recommend. no docs available for how to use autocompletion on any repos now afaik

To get exec to work on windows, something special needs to be done. Not sure what it is. Also need to update current tests.

When using npm@3 I get error logs about gulp-cli having extraneous packages.

Example;

npm ERR! extraneous: [email protected] /Users/MarkZuckerberg/.nvm/versions/node/v0.12.7/lib/node_modules/gulp-cli/node_modules/gulp-cli

Not sure if this happens due to npm@3 or if gulp-cli installs a new version of itself by itself.

Something like:

        function printTaskTree(tasks, taskKey, indent) {
            var taskObject;
            taskObject = tasks[taskKey];
            if (taskObject) {
                console.log(indent + (taskObject.name ? taskObject.name : taskKey));
                if (taskObject.dep) {
                    taskObject.dep.forEach(function(name) {
                        printTaskTree(tasks, name, indent + '  ');
                    });
                }
            }
        }

        printTaskTree(gulp.tasks, 'default', '');

(Moved from gulpjs/gulp#1098)

The gulp program that comes with the gulp-cli package (0.2.0) doesn't find gulpfile.babel.js. Uninstalling gulp-cli and globally installing gulp fixed the problem so this isn't urgent, but it seems like gulp-cli should work.

Needs to be done by @contra

Npm install fails when having gulp-cli as dependency and gulp as devDependency. This is probably because both of them try to link their own gulp bin.

∴ slush git:(4.0) npm install

> [email protected] install /Users/heikki/Desktop/heikki/slush/node_modules/gulp/node_modules/v8flags
> node fetch.js


> [email protected] install /Users/heikki/Desktop/heikki/slush/node_modules/gulp-cli/node_modules/v8flags
> node fetch.js

npm ERR! Darwin 14.0.0
npm ERR! argv "node" "/Users/heikki/.nvm-fish/v0.10.35/bin/npm" "install"
npm ERR! node v0.10.35
npm ERR! npm  v2.1.17
npm ERR! path ../gulp-cli/bin/gulp.js
npm ERR! code EEXIST
npm ERR! errno 47

npm ERR! EEXIST, symlink '../gulp-cli/bin/gulp.js'
File exists: ../gulp-cli/bin/gulp.js
Move it away, and try again. 

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/heikki/Desktop/heikki/slush/npm-debug.log

23:39:28][Step 2/2] Executing C:\TeamCity\buildAgent\work\8c63f769a91ad7c1\node_modules\.bin\gulp.cmd via wrapping shell script
[23:39:28][Step 2/2] Starting: cmd /c C:\TeamCity\buildAgent\work\8c63f769a91ad7c1\node_modules\.bin\gulp.cmd <snip> build-develop
[23:39:28][Step 2/2] in directory: C:\TeamCity\buildAgent\work\8c63f769a91ad7c1
[23:39:39][Step 2/2] [23:39:39] Using gulpfile C:\TeamCity\buildAgent\work\8c63f769a91ad7c1\gulpfile.js
[23:39:39][Step 2/2] [23:39:39] Task never defined: build-develop
[23:39:39][Step 2/2] [23:39:39] Please check the documentation for proper gulpfile formatting
[23:39:39][Step 2/2] Process exited with code 0

I'm running gulp 4, and it looks like it exits with 0 even when there is an error.

I have raised PR #77 to update dependencies and include snyk as part of the default test suite for vulnerability checking.

Normally I would snyk test --dev to ensure devDependencies are included (since this mirrors the default behaviour of npm install without the --production flag) however this would cause a failure as a number of vulnerabilities are present.

As these are principally related to the github-changes dependency, which you're using to generate your CHANGELOG.md I decided to raise an issue for comment to ensure any fix is in line with the project's goals.

✗ Low severity vulnerability found on [email protected]

• desc: Regular Expression Denial of Service
• info: https://snyk.io/vuln/npm:hawk:20160119
• from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Low severity vulnerability found on [email protected]

• desc: Regular Expression Denial of Service
• info: https://snyk.io/vuln/npm:hawk:20160119
• from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ High severity vulnerability found on [email protected]

• desc: Content & Code Injection (XSS)
• info: https://snyk.io/vuln/npm:marked:20150520
• from: [email protected] > [email protected] > [email protected]
  Fix: None available. Consider removing this dependency.

✗ High severity vulnerability found on [email protected]

• desc: Content & Code Injection (XSS)
• info: https://snyk.io/vuln/npm:marked:20150520
• from: [email protected] > [email protected] > [email protected] > [email protected]
  Fix: None available. Consider removing this dependency.

✗ Low severity vulnerability found on [email protected]

• desc: Regular Expression Denial of Service
• info: https://snyk.io/vuln/npm:moment:20160126
• from: [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Low severity vulnerability found on [email protected]

• desc: Regular Expression Denial of Service
• info: https://snyk.io/vuln/npm:moment:20160126
• from: [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Low severity vulnerability found on [email protected]

• desc: Regular Expression Denial of Service
• info: https://snyk.io/vuln/npm:moment:20160126
• from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
  Your dependencies are out of date, otherwise you would be using a newer moment than [email protected].
  Try deleting node_modules, reinstalling and running snyk test again.
  If the problem persists, one of your dependencies may be bundling outdated modules.

✗ Low severity vulnerability found on [email protected]

• desc: Regular Expression Denial of Service
• info: https://snyk.io/vuln/npm:moment:20160126
• from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
  Your dependencies are out of date, otherwise you would be using a newer moment than [email protected].
  Try deleting node_modules, reinstalling and running snyk test again.
  If the problem persists, one of your dependencies may be bundling outdated modules.

✗ Medium severity vulnerability found on [email protected]

• desc: Denial of Service (Memory Exhaustion)
• info: https://snyk.io/vuln/npm:qs:20140806
• from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Medium severity vulnerability found on [email protected]

• desc: Denial of Service (Memory Exhaustion)
• info: https://snyk.io/vuln/npm:qs:20140806
• from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Medium severity vulnerability found on [email protected]

• desc: Denial of Service (Event Loop Blocking)
• info: https://snyk.io/vuln/npm:qs:20140806-1
• from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Medium severity vulnerability found on [email protected]

• desc: Denial of Service (Event Loop Blocking)
• info: https://snyk.io/vuln/npm:qs:20140806-1
• from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Medium severity vulnerability found on [email protected]

• desc: Remote Memory Exposure
• info: https://snyk.io/vuln/npm:request:20160119
• from: [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Medium severity vulnerability found on [email protected]

• desc: Remote Memory Exposure
• info: https://snyk.io/vuln/npm:request:20160119
• from: [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Medium severity vulnerability found on [email protected]

• desc: Remote Memory Exposure
• info: https://snyk.io/vuln/npm:request:20160119
• from: [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Medium severity vulnerability found on [email protected]

• desc: Remote Memory Exposure
• info: https://snyk.io/vuln/npm:request:20160119
• from: [email protected] > [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Medium severity vulnerability found on [email protected]

• desc: semver Regular Expression Denial of Service
• info: https://snyk.io/vuln/npm:semver:20150403
• from: [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

✗ Medium severity vulnerability found on [email protected]

• desc: semver Regular Expression Denial of Service
• info: https://snyk.io/vuln/npm:semver:20150403
• from: [email protected] > [email protected] > [email protected] > [email protected]
  No direct dependency upgrade can address this issue.
  Run snyk wizard to explore remediation options.

Tested 721 dependencies for known vulnerabilities, found 7 vulnerabilities, 18 vulnerable paths.

Moved from gulpjs/gulp#1180

This may be trivial, but the Coveralls badge link 404s.

gulp-util.log checks for hasGulplog on module initialization and if present, defers logging to gulplog.info, which in turn will eat any messages below error (I believe) unless there is explicitly an event handler for the other levels (info, warn, etc.).

This can happen 'accidentally' if a transitive dependency uses gulplog.

It seems like the reasonable thing to do is to use gulplog.error to ensure all logging is output properly.

~/src/foo $ gulp
[10:33:45] Using gulpfile ~/src/foo/gulpfile.js
/Users/ibc/.npm-packages/lib/node_modules/gulp-cli/index.js:133
    gulpInst.start.apply(gulpInst, toRun);
                  ^
TypeError: Cannot read property 'apply' of undefined
    at /Users/ibc/.npm-packages/lib/node_modules/gulp-cli/index.js:133:19
    at process._tickDomainCallback (node.js:381:11)
    at Function.Module.runMain (module.js:503:11)
    at startup (node.js:129:16)
    at node.js:814:3

~/src/foo $ gulp -v
[10:33:51] CLI version 0.1.3
[10:33:51] Local version 4.0.0-alpha.1

It also happens with latest gulp-cli 0.3.0 (gulp-cli is globally installed).

NOTE: Using local gulp 4.0.0-alpha.1 and global gulp-cli 0.1.3 worked fine until I upgraded gulp-cli to 0.3.0. Then the error above happended, but worse, once I reverted to 0.1.3 the problem still happens, so it may be due to an updated dependency within gulp-cli (just wondering).

I wish I could be more specific in the title, but I have no idea what the issue is in here :)

Setup: windows + [email protected] + gulp@#4.0

Error after runing gulp inside d:\websites\project:

[15:12:17] Working directory changed to d:\websites\project
[15:12:18] Using gulpfile d:\websites\project\gulpfile.js
C:\Users\Darsain\AppData\Roaming\npm\node_modules\gulp-cli\index.js:133
    gulpInst.start.apply(gulpInst, toRun);
                  ^
TypeError: Cannot read property 'apply' of undefined
    at C:\Users\Darsain\AppData\Roaming\npm\node_modules\gulp-cli\index.js:133:19
    at process._tickCallback (node.js:372:11)
    at Function.Module.runMain (module.js:503:11)
    at startup (node.js:124:16)
    at node.js:842:3

Moved from gulpjs/gulp#574

Tasks should be able to delay the timeout notification, as they are based able to determine if intensive work is being done. Otherwise, gulp-cli cascades the "Task did not complete after 10s." notification for everything in-flight, which in my case could include a number of orchestration tasks ("default", "series', "parallel", then finally the two tasks that are hard at work and eventually complete)

Ref #24 (comment)

We need more exec tests.

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

The common case is export const dist = series(clean, css); which is broken because series/parallel get displayName attached. Ref b7da669#commitcomment-15987378

In 1.2.0, @sttk added a --depth flag to gulp-cli; However, we didn't apply it to the --tasks-json flag to reduce the exponential growth as described in gulpjs/gulp#1033

@sttk If you or anyone else would like to expand on the functionality you added for --depth and apply it to --tasks-json, that would be super helpful.

Must wait for #69 to be implemented.

Moved from gulpjs/gulp#1534

I'm envisioning this as a description property in the .gulprc file that replaces https://github.com/gulpjs/gulp-cli/blob/master/lib/versioned/%5E4.0.0/index.js#L57, https://github.com/gulpjs/gulp-cli/blob/master/lib/versioned/%5E4.0.0/index.js#L49 and https://github.com/gulpjs/gulp-cli/blob/master/lib/versioned/%5E4.0.0/index.js#L67 (and corresponding versioned files).

Right now, WebStorm parses the output of gulp --tasks to capture the tasks that can be run. I'm testing this with the v4 alpha of both gulp and gulp-cli. I have a very simple gulpfile with a single task. I've noticed that the output from running gulp --tasks now has two spaces appended to my task name. So when WebStorm parses the task tree, it attempts to run gulp "clean " which does not exist (notice the two trailing spaces).

I've already submitted a bug to Jetbrains letting them know that they should probably trim the task names after parsing them. I see a couple of things that could be improved on the gulp side too. I think the first and most obvious step is to remove the trailing spaces from the task tree output. I have a couple of other ideas also.

I know gulp uses Liftoff for CLI work so maybe it can't be easily addressed directly in the gulp project, but I'm thinking the gulp-cli should trim the tasks arguments that are passed in just as a simple normalization step. I don't think anyone should be defining tasks with whitespace on either side so this shouldn't cause a problem. That would create a simple fix for any other tooling out there that parses the task tree and does not do its own trim. This is to keep existing tooling happy and not cause any backward compatibility issues.

It could be taken one step further though and I may be interested in spending some time implementing it. There should be a separate CLI flag that can be used by other tooling that outputs to something that does not need to be manually parsed. I'm thinking a simple object graph version of the tree serialized to JSON and written to stdout. This should help to make any tooling integration with gulp easier.

Update:
I just noticed that gulp is using archy, which means this object is probably already defined somewhere.

I implemented support for printing task description to the console a while ago (see #19 ). I added support for this property both on branch master and 4.0.
I just tested this feature today and realized that, when using gulp 3.X, task descriptions never print to the console. Looking at the code a bit, I realized that the code responsible for logging the task-tree in Gulp 3.X is located in the gulp module itself, and not in gulp-cli: https://github.com/gulpjs/gulp/blob/master/bin/gulp.js#L133

So it seems that, despite all necessary code is present in gulp-cli, this code is ignored and the description is never printed. Can you confirm this is the case? (I'm surprised I didn't test it and realized it earlier, I'm wondering if there might be something wrong on my machine).
And if it's the case, would there be a way to update Gulp 3.X and actually use the code in gulp-cli to display the description?

Thank you in advance : )

Ref gulpjs/gulp#361

I just did a new install of gulp with and without the global flag. After that I tried to run a task and got the following error:

C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\semver\semver.js:281
throw new TypeError('Invalid Version: ' + version);
^

TypeError: Invalid Version: undefined
at new SemVer (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\semver\semver.js:281:11)
at SemVer.compare (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\semver\semver.js:350:13)
at compare (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\semver\semver.js:574:31)
at Function.gt (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\semver\semver.js:603:10)
at Liftoff.handleArguments (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\bin\gulp.js:103:14)
at Liftoff.<anonymous> (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\liftoff\index.js:192:16)

at module.exports (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\liftoff\node_modules\flagged-respawn\index.js:17:3)
at Liftoff.<anonymous> (C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\liftoff\index.js:185:9)
at C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\liftoff\index.js:159:9
at C:\Users\USERNAME\AppData\Roaming\npm\node_modules\gulp\node_modules\v8flags\index.js:99:14

It turns out in gulp.js inside the handleArguments function, env.modulePackage.version is undefined. It gets this from Liftoff so possibly Liftoff isn't doing its job or gulp is calling it wrong or something with my mchine is messed up.

If I give it a value everything works fine:

env.modulePackage.version = env.modulePackage.version || '3.9.0';

Node version: 4.0.0
npm version: 2.14.2
gulp-cli version: 3.9.0
gulp local version: 3.9.0

As far as I can see, getting Node to use io.js would just just be a case of changing the hashbang (and the one in gulp). Liftoff has no problems with io.js: gulpjs/liftoff#30

Is there a way to support io.js which doesn't involve switching the entire project to use it? Say, if I want to use io.js in my gulpfile.js.

Is this something people like and would want? We would use https://github.com/yeoman/update-notifier like yeoman does.

cc @sindresorhus

I can't find any docs on this, but before to install gulp#4.0 you'd have to install the gulp-cli#4.0 branch globally. However, there is no more gulp-cli#4.0 branch. I don't see in the changelog or any merge's that brought it into master. Is there a new pattern for install gulp#4.0 that we should be following?