Bin conflict with gulp & gulp-cli

[heikki]

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

> v8flags@1.0.8 install /Users/heikki/Desktop/heikki/slush/node_modules/gulp/node_modules/v8flags
> node fetch.js


> v8flags@1.0.8 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

[heikki]

Is gulp-cli meant to be installed globally in the future? I'm wondering if both of them need the bin.

I run into this issue in my slush fork: https://github.com/heikki/slush/tree/4.0

[phated]

gulp-cli was meant to be installed globally but then aliased in gulp so when it is installed locally, you can easily do gulp whatever in npm scripts inside package.json without adding gulp-cli to your devDeps. This was a problem @tkellen pointed out with grunt's approach to grunt-cli. His comment is gulpjs/gulp#805 (comment)

[tkellen]

Whoops, didn't read this code yet. By making gulp-cli a dependency of gulp it should make gulp available in node_modules/.bin when installed locally, but it won't make it available globally--for that you'd have to install gulp-cli. Let me confirm these assumptions later today, it's been a long time since I looked at this.

[heikki]

I'd be happy to use a workaround for this case. So far I have found only bad ones 😄
Anyways, there could be issues if people install both gulp & gulp-cli locally or globally.

"postinstall": "[ \"$NODE_ENV\" == \"production\" ] || npm install gulp"

[tkellen]

So, my previous assumptions were incorrect, but, @heikki why are you depending on both gulp-cli and gulp at the same time? You should never need gulp-cli in your dependencies, just install the version of gulp you want and it'll have the binary you need.

[heikki]

@tkellen I linked the slush fork above. I'm trying to modify slush to use gulp-cli instead of copying the same code there. gulp was there just for tests i.e. there's a gulpfile that gets called by slush.

Workaround is fine for me. I just thought to bring this up because I'd imagine ppl can get easily things messed. For example install both globally, then uninstall one and boom there's no bins anymore.

Should this be closed as wontfix or is there alternatives left?

[tkellen]

Unfortunately, I think this is a wontfix, both because I think your particular implementation is enough of an edge case, and because I can't think of a good solution :/.

[tkellen]

cc @contra was going to close this but looks like I don't have privs here? Just checked for the gulp repo--same deal.

[phated]

@heikki I'd like a way to solve this but we really only have 2 options:

1. Have as a dep of gulp and have the clashing bins when installed next to each other. - I want to look into npm further to see if we can avoid failing, like an optional bin or something
2. Make gulp-cli a peerDep of gulp so they both get installed upon npm install, this works with --save but the remove doesn't. On top of that, peerDeps have a lot of weird edge cases.

[heikki]

3 . Remove bin from gulp-cli and keep using gulp for both local & global installs

Global install would be bigger but wouldn't it solve this issue? Am I overlooking something?

[phated]

It's a versioning thing. It will be confusing that gulp 3.whatever globally installed can run gulp 4.whatever but only if it is local. Having a separate (smaller being another benefit) module that is versioned separately makes that distinction easier.

[heikki]

I agree. I'd still rather have that if it prevents breaking things accidentally. I usually install global modules without specifying version and occationally update all of them to latest and expect that things keep working. Random notes:

• Separating gulp-cli would still have benefits (including only code, no bin)
• From user perspective local/global gulp would keep working as usual
• 'Warning: gulp version mismatch:' could be more explicit 'Warning: global gulp is outdated, please run npm update -g gulp' or similar
• Crazy idea of using only global gulp for quick tests might be possible Split CLI out into a module gulp#827 (comment)

--edit

Just noticed that 4.0 branch warnings are already different

[phated]

Currently, local/global already works as expected. You can still install gulp globally and have it work. That is the reason for the duplicate bin files. I don't like the hack to work with NODE_PATH because it will work when the bug in the resolve module is fixed.