Gulp 3.x CLI does not support both versions of gulp

[ibc]

If I use gulp branch 0.4 within my local project but then run gulp 0.3 (installed globally) then I get an error:

$ gulp
[12:24:51] Using gulpfile ~/src/xxxxx/gulpfile.js

/Users/ibc/.npm-packages/lib/node_modules/gulp/bin/gulp.js:129
    gulpInst.start.apply(gulpInst, toRun);
                   ^
TypeError: Cannot call method 'apply' of undefined
    at /Users/ibc/.npm-packages/lib/node_modules/gulp/bin/gulp.js:129: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

May I know why gulp does not provide a separate module gulp-cli (similar to grunt-cli) whose only purpose is to locate the local gulp executable path (or the global one if not present locally)?

The idea of grunt-cli is to avoid issues as the described above. I consider it extremely useful.

[yocontra]

@ibc We don't need two modules, it functions the exact same way.

global = CLI
local = everything else

As for the 3 -> 4 global shift, we can do something about that.

@phated The CLI should probably do what grunt-cli does and just load the local CLI vs. running a global CLI version and using local code. This will help prevent incompat between major bumps

[ibc]

@ibc We don't need two modules, it functions the exact same way.
As for the 3 -> 4 global shift, we can do something about that.

Well, I will agree when I can run my global gulp 0.3 CLI within my local gulp 0.4 based project and vice-versa ;)

[yocontra]

@ibc 4 is not finished, it's still being worked on.

[pkozlowski-opensource]

It would be totally awesome to be able to run different local versions of Gulp (3/4) with one globally installed version (3 or 4 - doesn't matter). IMO it would encourage people to try out Gulp4, provide feedback, catch back so it could be out sooner, so the World would be more awesome!

[yocontra]

@pkozlowski-opensource I'm not sure where the incompat lies, I'll check it out

[phated]

grunt split out into the grunt-cli that used the local grunt package. pinging @tkellen and @cowboy to figure out what it attempted to solve and if it worked. I need some real world exp to know which way to proceed.

[stringparser]

what about making it a function call @phated? i.e. gulp.cli()

[stringparser]

I mean, one could check process.argv to see if which gulp was there and then launch the cli. Or let the user lauch it from a simple node program

[tkellen]

grunt-cli was created to address this exact problem. our codebase was never re-factored to remove the grunt dependency in the cli itself, which makes our usage of this pattern a little strange, though (it needs to be there for the help functionality and a bunch of other things).

anyway, assuming you make breaking changes to how gulp is invoked, the idea is that the cli would contain heuristics for detecting which version was required, and then invoke gulp appropriately. you might not need this if the invocation pattern remains the same across major versions, but you will undoubtedly find some in the community confused about what version of gulp they are using if you don't provide a version-agnostic launcher or some very accessible documentation to explain what is happening.

i think gulp-cli makes a ton of sense to solve this problem, but given how small the gulp codebase is already, i can see how it would feel strange.

if you do decide to do this, one thing i would recommend doing differently is making the cli a dependency of gulp itself, that way local installs have access to ./node_modules/.bin/gulp without having to install gulp-cli alongside gulp.

[ibc]

+1

[stringparser]

+1