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

[demisx]

+1

[yocontra]

@phated What changes were made to the CLI for 4.0? I think we can solve this issue really easily by just making the CLI work with 3 and 4 on both branches. That seems so much easier than doing some craziness of splitting out into new modules to have different CLIs that can co-exist

[phated]

@contra I like the idea of the separate CLI. Lots has changed but it can be made backwards compat. I like the idea of a smaller global install.

[phated]

All code currently in the 4.0 branch is related to the CLI and not to the core lib. I think that should be tested using spawn/exec (ping @terinjokes) and then just have some smoke tests for the gulp public API

[yocontra]

@phated Saving bytes on a global install is a problem to be solved but isn't really related to why this issue was opened. I think cross-compat is a good first step, and we can split it out later if install size is really an problem (we should probably make a new issue for that). I haven't seen anybody complain about global install size though since you only have to do it one time.

[phated]

@contra it's a code maintainability standpoint for me. The cli being bundle causes me more headaches than it solves. It's not a large amount of work to break it out and still support back compat with 3.x

[yocontra]

@phated I understand that from a code maintainability standpoint it makes sense to split it out. You have no argument from me: it should be split out. I 100% agree with everyone in this thread. Splitting it out has nothing to do with this issue though, which is about having a CLI that supports gulp 3 and 4. If we want the gulp 3 branch to support running 4 gulpfiles we are going to need to keep the CLI structure the same so splitting isn't an option. For the 4.0 branch we can split the CLI out and that can support 3 and 4.

I think the first thing we need to do is write the cross-compat code. Where it goes will depend on which branch (3 or 4). Conflating the two things (splitting out and cross-compat) is going to cause confusion and prevent this issue from being closed.

[phated]

Glad we all agree. If you'll create the repo, I believe I can get it working for 3.x and then add in the functionality to make 4.0 work and keep it backward compat. As @tkellen said, we can just require the gulp-cli module.

[yocontra]

@phated Yep that makes the most sense to me. I'll make a new issue for splitting it out and link the new repo there

[yocontra]

#827

[phated]

Should be working in gulpjs/gulp-cli#4.0 and #4.0 now. Give it a shot and let me know if it works.

[ilanbiala]

Can this issue be closed now that the CLI compatibility is fixed?

[heikki]

@ilanbiala gulpjs/gulp-cli#4.0 branch needs to be merged first and there's a blocker gulpjs/gulp-cli#7

[Aetet]

Maybe just rename CLI call to: gulp4 default or write tool like nvm do the trick?

[phated]

As of now, gulp-cli has a published 1.0.0 - https://www.npmjs.com/package/gulp-cli

Closing this as completed.

[tkellen]

Woohoo!!
On Nov 18, 2015 6:56 PM, "Blaine Bublitz" [email protected] wrote:

Closed #805 #805.

—
Reply to this email directly or view it on GitHub
#805 (comment).

[postor]

same problem, solved this way

node ./node_modules/gulp/bin/gulp.js -v
[16:21:56] CLI version 1.2.2
[16:21:56] Local version 4.0.0-alpha.2

but this really works

node ./node_modules/gulp/bin/gulp.js

Loading engines...
...scanning for engines in the core...
...scanning for engines in the edition or test directory...
- mustache engine: good to go
...done loading engines.