Shouldn't be a gulp plugin

[sindresorhus]

This should just be a vanilla node module. Please read the plugin guidelines.

[janraasch]

Obviously this is more fun than profit, but there are actual gulp use cases, e.g. this can be used as a reporter running on a build server for lint or test plugins.

Like so

var message = function (file) {
        ret = "";
        if(file.jshint.success) {
            ret = file.relative} +  " is lint free."
        else {
            ret  = file.relative + " has problems."
        }
        return ret;
};
gulp.src('./{,test/}*.js')
    .pipe(jshint())
    .pipe(twitter(oauth, message));

Also, see the project's gulpfile for an example.

Probably I should add this as the usage example on the readme.md. What do you say?

[sindresorhus]

You could make it gulpfriendly by changing out the gulpplugin keyword with gulpfriendly, but I think making it a vanilla node module and let the user use through2 instead.

[janraasch]

You are right. Actually that is all this plugin really does: Add through2 to the vanilla node-twitter-api. I like to keep it around for now. So I can reuse even the little abstraction it does.

[rschmukler]

@sindresorhus surely you have better things to do than troll people's githubs... How is this that different from what gulp-mocha does, other than it has less utility? (I'm not even trying to be a dick here, I am honestly curious how we should make the distinction)

[sindresorhus]

@rschmukler Not trolling at all. We're trying to actively keep the quality up, unlike every other community. We also don't want to see silos created unnecessary when a vanilla node module would easily do. You're right about gulp-mocha. It was a bad idea (though keep in mind it was created early on), and we might deprecate it.

[rschmukler]

@sindresorhus sorry, I shouldn't have been so rude. I am actually not advocating for the deprecation of gulp-mocha.

I understand with what your saying, but these little "gulp plugins" still save me having to write 80 lines of code, and they impress upon people evaluating which build-system to use. People unfamiliar with build systems often evaluate based on the amount of plugins they see and what they do. "Mocha? check. Coffeescript? Check. Jade? Check". While they might not be the most valuable assets to the community initially (they might not understand what gulp truly does, etc) you never know who will become a contributor.

I worry that the community might not grow into what it could be if we take the philosophy of "just roll your own with through2 and a standard node module"; it's a rather high barrier to entry for the low gains of omitting some packages from search results (gulpplugin keyword).

I was trying to figure out how I could think about it for it to make sense as to when something should be a plugin or not.

• Should we be transforming the data? What about gulp-livereload? Again, this could be done with through2. Even gulp.dest isn't really "transforming" the data.
• Should we be manipulating the streams with things like filtering, flow control? That's what gulp-filter does, and yet it could be abstracted into a more generic stream filtering library instead of a pure plugin.
• Should we only be creating plugins for something with a higher level of complexity? What about gulp-concat, gulp-header and gulp-footer?

Like I said, I am not trying to be hostile with this at all. I am simply confused when it is appropriate to create a plugin, and when we should be putting it in our own build. Hoping you can help me understand! Cheers.

[sindresorhus]

but these little "gulp plugins" still save me having to write 80 lines of code

I think you're misunderstanding. I'm not saying you shouldn't create reusable code. Quite the opposite. I'm just trying to advocate a better way of doing so. Gulp plugins should work on the file buffer, like transforming it somehow. If it don't, it's not really a plugin and could just be a vanilla node module you use in your gulpfile. Do realize gulp is just node. You can do whatever.

People unfamiliar with build systems often evaluate based on the amount of plugins they see and what they do

Well that's like measuring code quality by the lines of code, which is stupid. Gulp has already covered the main concerns with all transpiler/template-engines/etc. Grunt has passed 2000 plugins. 1900 of them are crap. We don't want to end up like that. Less is more, or better yet quality over quantity.

I worry that the community might not grow into what it could be if we take the philosophy of "just roll your own with through2 and a standard node module";

Well by creating vanilla node modules instead you'll grow the whole eco-system, not just the gulp silo. Gulp is part of the node eco-system. Embrace it.

Should we be transforming the data? What about gulp-livereload? Again, this could be done with through2. Even gulp.dest isn't really "transforming" the data.

Yes, please read the plugin guidelines. It explains everything.

gulp-livereload I believe is an exception for ease of use.

Should we be manipulating the streams with things like filtering, flow control? That's what gulp-filter does, and yet it could be abstracted into a more generic stream filtering library instead of a pure plugin.

That's not correct. gulp-filter only works on vinyl streams: https://github.com/sindresorhus/gulp-filter/blob/cff7cafa50640b5d23470c834ca6a962bc43ed07/index.js#L23

But yeah, in general you should use the existing stream modules. No need to reinvent the wheel and create silos when you don't have to.

Should we only be creating plugins for something with a higher level of complexity? What about gulp-concat, gulp-header and gulp-footer?

Rather the opposite. Plugins should be simple and do one thing well (again from the plugin guidelines). We welcome small focused plugins that manipulates the file buffer. The rest should just be node modules.

---

@contra

[rschmukler]

small focused plugins that manipulates the file buffer. The rest should just be node modules.

This seems like a good way of putting it.

I've read the plugin guidelines numerous times, and they are useful. What I don't understand is the exceptions, and that often, the most popular gulp plugins are those exceptions. gulp-mocha, gulp-livereload, gulp-notify.

Again, thank you for your responses.

[janraasch]

Love the discussion. Many thanks to @sindresorhus for clarifying things.

I have been wondering about the fate of gulp-mocha pretty much, since browsing through @contra's inspiration slides for the first time back at the end of last year.

I think it would set a great example for the community to deprecate gulp-mocha.

[yocontra]

Test running is an okay case for gulp, but not a great one. Most test runners were not built to be run programmatically and this has caused a lot of issues and led to really crappy plugins that don't do the job very well. I'd like to start deprecating some of the crappy test runner plugins in favor of just putting the CLI npm test and making a plugin that runs npm test on stream end