Cede the package name on NPM to gulp-bro

[chocolateboy]

cc @ngryman, @romeovs, @substack

First off, thanks for this package! It has clearly served a large number of users very well over the years, and the work that has gone into it is much appreciated. So much so, in fact, that far from allowing it to fade away, I'd like to suggest a way for it to live on and prosper...

Since this package no longer works and is no longer being maintained, how about yielding its name on NPM to gulp-bro, which a) works, b) works well, and c) is actively maintained?

(I have a theory that the extremely bad experience developers have getting Gulp and Browserify to work together was the main reason they flocked to Webpack. Out of the box, the gulp+browserify experience is... well, there is no out of the box. There are just abandoned packages accumulating issues, and vague instructions to figure out the solution from a bunch of poorly-organised "recipes" full of exactly the kind of bloated boilerplate we expect plugins to deliver us from.)

The only problem with gulp-bro is that no-one's heard of it. (It's not in the first 10 pages of Google results for me. I gave up after that.) All of these issues can be closed by directing users to gulp-bro, so why not simply allow gulp-bro to become gulp-browserify 1.0 or 2.0 so that the first result(s) when you google gulp + browserify Just Works™?

If not, then please, at least, update the README to point users to gulp-bro.

[download13]

I just realized I don't actually have control over the npm package (not that I've done anything that would need it).

@deepak1556 Do you have any thoughts on this?

[ngryman]

Hey,

IMHO, a mention in the README would ok as it would point to a direct alternative to gulp-browserify.

[chocolateboy]

@ngryman So, to be clear, you don't want this package name/alias?

[ngryman]

@chocolateboy I didn't say that, but changing name would involve passing by @deepak1556 each time I want to publish on npm, confusion with old links pointing to this repo and my repo, a migration guide, ...

A common practice in the community is just to deprecate a repo and link to an up-to-date one. That's what I propose.

[patricknelson]

Thanks to this thread, I'm now using gulp-bro (after frustrating myself with watchify) and I can confirm: it works great!

[patricknelson]

p.s. I can tell this is a pretty important issue, considering it's still getting thousands of downloads per day despite the big fat THIS PLUGIN IS NO LONGER MAINTAINED warning at the very top of the package page. I'm thinking more and more people are going to encounter issues like I did (e.g. gulpjs/gulp#222 (comment)) as they manually patch browserify into their gulp workflow.

[download13]

I'm not sure what the owner wants to do about the package name, but in the mean time I've added a link to gulp-bro in the README.

3481b65

[KenEucker]

I just want to jump in here and say that I was using this package for a while until I discovered the deprecated status. It would be nice if there was a deprecation warning on install.

At the very least, the community of 11,000 weekly downloads in 2019, people could really benefit from having the dependencies updated at the minimum. I attempted to change to gulp-bro, but the required changes to my code created a barrier to that and I never revisited it.

Now, with dependencies that have security issues and several deprecation warnings on install, I am forced to go another route. If any maintainer sees this message and is able to make some minimal updates -- it would be great to see a response.

[ngryman]

Hey @KenEucker, I'm the author of gulp-bro. I've got a pretty limited time to allocate to it but if it's only giving some fresh air to dependencies and tweak the code a little bit, I could potentially do that. Would you mind opening an issue in the gulp-bro repo and add some details about what's blocking you? Thanks.