Skip to content
This repository


Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

grunt-contrib #15

tkellen opened this Issue September 10, 2012 · 11 comments

3 participants

Tyler Kellen Jake Harding Ben Alman
Tyler Kellen

Hiya Jake,

I maintain the grunt-contrib series of tasks; I was wondering if you had tried our less task? If so, did you run into any issues with it?

One of the main goals of the grunt-contrib project is to lessen duplication of effort and fragmentation in the JS development community. We've had tons of great contributions over the last six months--if you'd be willing to share your additions I would greatly appreciate it!

Jake Harding

Can't say I've tried out grunt-contrib-less, however I have scanned over the documentation for it previously. I'd be more than happy to contribute to grunt-contrib, what'd you have in mind?

Tyler Kellen

Basically, I'm looking to eliminate duplication of plugins within the grunt ecosystem. Most of the active participants in grunt-contrib are also working on grunt proper, and we're committed to maintaining the contrib series for the long haul. If our task covers your needs, would you be willing to yank yours? If it doesn't, would you be willing to help us improve it so it does?

Jake Harding

I don't think you're suggesting this, but just in case you are, removing grunt-less from npm isn't a viable option in my opinion. Based on the download numbers from, a decent number of projects depend on grunt-less and I wouldn't want to break anything for the dependents of it. However, deprecating grunt-less could be an option if it came to that.

While I appreciate your efforts in trying to eliminate duplication of plugins within the grunt ecosystem, I kind of enjoy duplication, it means more choices! Sure, grunt-less and grunt-contrib-less serve the same general purpose, but the format of their configs are different and they expose different options to the less compiler. Based on those differences, let devs decide which plugin they're more comfortable with.

Also, with the overhaul to, having a polluted ecosystem isn't as big of deal as it used to be. Now that embraces the power of Google, it's pretty easy to find the quality modules.

Finally, I like the idea of grunt-contrib (making it easy to find quality plugins), however I think you guys are going about it in the wrong way. Rather than having grunt-contrib be a collection of plugins from the grunt-contrib team, grunt-contrib should be a collection of quality plugins from the ecosystem. With the way things are now, what happens if someone releases a plugin that's a duplicate of a grunt-contrib plugin, but happens to be way better?

Tyler Kellen

Thanks for the thorough and thoughtful reply. I did mean depreciate, not yank. We actually expose the same options to the less compiler--our task documentation should be more clear about how options are passed!

All of the tasks in grunt-contrib have come from the community. We regularly receive PRs for new tasks (yuidocs being the most recent). The primary benefit of having them under one organization (in my view) is that people seem more apt to contribute improvements to an established project. All but one or two of our tasks have received numerous PRs for improvement. Another benefit is that tasks will always be kept in sync with grunt's API (which is currently undergoing some serious refactoring).

If someone releases a plugin that duplicates / greatly improves on a grunt-contrib task, I would approach them in a similar manner as I have you, asking if they'd be willing to participate in the contrib project. Assuming they were interested, they'd be able to lend their expertise to all of our tasks. To me, this seems objectively better than having several single-developer solutions with no easy way to distinguish between them.

Jake Harding

Everything you mention seems pretty reasonable. I'm questioning whether or not deprecating grunt-less is the best idea though. The name "grunt-less" kind of implies it's the plugin you should use when it comes to less. What are your thoughts on me potentially transferring the grunt-less repo over to the grunt organization? You guys could then have full control over it and take advantage of the name. You'd have to get away from your current scheme where every plugins' name within grunt-contrib beings with "grunt-contrib-", but if you're ok with that, I think this could be a solid option.

Tyler Kellen

At the moment, I think we are going to stick with the "grunt-contrib" prefix for tasks. Mainly because it provides an obvious distinction within the ecosystem.

I'm not clear on the best course of action for handling this yet. You're the first person I've spoken with about this type of thing. I think a depreciation notice on the task stating that it will be going away as of grunt 0.4 would be pretty seamless? Upgrading to grunt 0.4 will require some changes config-wide anyway.


Jake Harding

In my eyes, there are 2 options:

  1. Deprecate grunt-less.
  2. Make grunt-less a mirror of grunt-contrib-less.

On the one hand, I feel like deprecating grunt-less could potentially confuse newcomers. Because of its name, I think for the most part, it'll always be the first plugin grunt users try when they're looking for a less plugin. It'd be a shame to put that name to waste.

On the other hand, making grunt-less a mirror of grunt-contrib-less might be more trouble than it's worth.

Ben Alman

I'm not sure how much these details matter. In the future, we're going to be promoting the contrib plugins pretty heavily, which should cause both users and plugin authors to be more aware of them and to use them more.

By combining efforts towards improving the contrib plugins, everyone's ideas (and contributions) will continue to be recognized as those plugins evolve and grow, so any suggestions you might have are more than welcome.

Jake Harding

Alright, I can deprecate grunt-less then. The deprecate message will along these lines:

This grunt plugin is no longer being maintained and it will not be compatible with grunt 0.4. Replacing your dependency of grunt-less with grunt-contrib-less is highly encouraged.

I'll try and get this done within the next few days. What's the ETA for grunt 0.4 by the way?

Ben Alman

Hard to say, I'm refactoring so many things!

Jake Harding

Deprecated grunt-less and updated the README to direct people to grunt-contrib-less.

Jake Harding jharding closed this September 16, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.