Skip to content

"Voiding the warranty" #432

cowboy opened this Issue Sep 17, 2012 · 22 comments

9 participants

grunt member
cowboy commented Sep 17, 2012

This is part of a larger discussion, but I have some pretty major concerns around tools like yeoman wrapping grunt.

General Confusion

There will be people using "wrapper tools" like this who don't know what grunt is and who will be confused. What parts belong to the wrapper, and what belong to grunt? Are they creating grunt tasks or "wrapper tool" tasks?


Some users will seek help for "grunt things" on the wrapper tool site. Some will seek help for "wrapper things" on the grunt site. Either way, behaviors between the two tools will be different, and it will be difficult to support. Where does that line get drawn?

Best Practices

Basically, the developers of the "wrapper tool" aren't me. They don't necessarily understand best practices for using grunt the way I do, and as such might create situations in which it's possible for people to create additional problems for themselves. Yes, grunt needs more documentation... but it's in development and things change frequently.


Only I know where grunt is going, if at all. Grunt is super-duper-pre-1.0 and might still change substantially before 1.0. It's probably going to be difficult and impractical to build a wrapper tool around a still-very-much-changing tool like grunt. What's the time delay between a new version of grunt being released and the wrapper tool incorporating those changes?


When a tool is written as a wrapper around grunt, the two brands can become conflated. People don't know where the line is drawn, and which tool is which. It would be unfortunate if someone mistook an issue in a wrapper tool for an issue in grunt. And vice-versa too, I want people to actually report issues on grunt if they are real issues.


It seems counter-productive to me to take focus away from grunt, especially at this early stage in its development, by introducing another tool in the ecosystem that effectively wraps grunt. We need to find a way to help the developers who would write grunt "wrappers" contribute back to grunt instead of creating yet another tool.

grunt member
cowboy commented Sep 17, 2012

Possible example of user confusion: yeoman/yeoman#484

kahlil commented Sep 25, 2012

You are raising very valid points here. I like the idea of Yeoman and what the creators want it to be.
But I am honestly still puzzled about the fact that they took grunt at this stage, which is gaining great traction and interest from lots of developers, and wrapped this massive thing around it.

It feels like there are so many possible points of failure there and it must be incredibly hard to maintain,
whereas grunt gives developers a simple tool to easily automate any build process that is most suitable to you.

It is weird too because Yeoman incorporates grunt and at the same time divides developers into camps Yeoman / Grunt.

What seems to be a sane solution here? Should Yeoman be even more abstract and high level to serve more specific needs?


My 2c FWIW.

I've helped out in a few spots with Yeoman (getting it installed on Windows for instance), and I've had some discussions regarding the generators used for AngularJS (as this affects me).

I was really excited about the prospect of Yeoman here initially, because it can give a bit of structure and 'best practices' to the application building process that is generally lacking for front-end development. At this stage, however, their Grunt wrapping and AngularJS tooling is not feature complete enough to ship something real-world that works for me. I find that there are a lot of customizations that you might want to make to a build process -- dev vs prod variations on how you run tests or what suites, etc, etc.

I don't know how they intend to handle these types of scenarios. Since you have to drop-down closer to Grunt, I'm not sure how their updating process will jive with this. It's a good way to scaffold out a project fast, but if you don't play entirely within the boundaries of Yeoman, I'm starting to feel a little reluctant about how Yeoman will be able to continue to play nice as your build process evolves and grows.


Feeling the same about the adoption rate of Grunt in Yeoman. Could see this really becoming a problem, especially considering the pace at which both are progressing. Not entirely sure I'd want to use that as a foundation right now, and risk lock-in on an old Grunt version. Especially when most of the benefit I see in such a tool/framework lies in its ecosystem.

For now my experience has been one of stripping down Yeoman-functionality in places where I wanted to customize the process, to a degree where it feels like it'd be better to just start with Grunt as a baseline from the start.


And especially Re: Brand:

I feel the main problem with drawing the line in Yeoman right now is the fact that it uses Grunt for it's init-tasks / generators as well as a part of the generated project, for you to use. I'm still starting out with both tools, but to me it feels like those two layers should be separated. E.g. using 'yeoman init *' to generate a project (I wouldn't really care if it uses Grunt in the background, or not. And in an ideal world I shouldn't have to) and direct grunt-tasks inside the generated project.
Right now Yeoman hijacks some behavior by Grunt to overwrite it with its own, and this seems to be the main confusion, at least for me, right now. Especially as those overwritten tasks are prone to compatibility-issues with plugins / tasks from the Grunt-ecosystem.
But may very well be me still not understanding Yeoman to its full extent yet.

grunt member
cowboy commented Oct 1, 2012

Related discussion happening in yeoman/yeoman#297.

@cowboy cowboy referenced this issue in yeoman/yeoman Oct 1, 2012

Yeoman as a grunt task #297

kahlil commented Oct 1, 2012
grunt member
tkellen commented Oct 16, 2012

@kahlil +∞

This is exactly what I've been doing with the grunt-contrib series for the past several months. We've seen tons of developer participation. Grunt 0.4 (coming soon, for real!) will also be going this route; we've pulled all the tasks out of the core and into the contrib project.

The issue of how to deal with init tasks remains, but we're going to get some systems set up that make it possible to build an ecosystem around those too.


Okay! Big delay on getting back to this thread...

To exonerate myself slightly, I was a vocal proponent of grunt-contrib from the early days and have seen (and still do) see it as the place for all best-in-class tasks to live. This provides enormous benefit for all users.

On to yeoman. the yeoman team met with the grunt team yesterday. full meeting notes here

As for this topic in particular:

  • yeoman will be upstreaming a few solo tasks into grunt-contrib (or at least, work with tkellen on figuring how best to do that).. tasks like img, misc, manifest
  • yeoman will upstream our generators setup (inspired by rails) into the grunt init implementation. ben's expressed interest in this for a while and we think we can share this code and all be happy here.
    • we'll first start with a design doc for everyone to review, and we'll continue the above two items with regular checks between yeoman and grunt folks.
  • we really want yeoman to play well within the grunt ecosystem and are focused on delivering a great end UX while still benefiting the larger community beyond our direct users.
  • we've actually brought on sindre as a contractor to devote dedicated time to this upstreaming effort

gotta run! ✈️

kahlil commented Oct 20, 2012

:bowtie: FUCK YEAH! :bowtie:

Sounds awesome congrats to @sindresorhus for the OSS gig 👍

❤️ ❤️ ❤️


This sounds really promising! Thanks for combining the efforts!

grunt member
Iristyle commented Nov 9, 2012

Looks good to me ;0

@DavidSouther DavidSouther referenced this issue in rmurphey/js-testing-boilerplates Nov 15, 2012

Global tool #1


I'm somewhat concerned from the differences between the current proposal posted by @sindresorhus on Nov 8th and the @paulirish meeting notes from Oct 18th. In the meeting notes, it seems that the goal for Yeoman was to focus on the generators, with consolidating workflow a consequence of that. From the current proposal, it looks more like the focus is on wrapping grunt, npm, and bower, pushing the generators into grunt:init. If that's the approach, that's fine, but seems to put Yeoman right back where it is now. I've posted my detailed concerns on the mailing list.

tl;dr: Yeoman as a generator is great. Yeoman as a tool to wrap the cli package and build tools is useless.

grunt member
tkellen commented Nov 15, 2012

I think you're missing a detail here David. Yeoman plans to completely subsume grunt-init, not upstream generators to it. When that happens, grunt init goes away. Then you'll be able to use Yeoman for scaffolding and Grunt for your build process.

I share your concerns about Yeoman trying to be a monolithic-do-everything tool, but given the decoupling that will happen internally with the next release, it doesn't seem like that big of a deal? Don't use the wrapped commands, whatever they might be.


Awesome! That's what I thought from Paul's post, but didn't come across in Sindre's post. I apologize for the confusion, and look forward to see where Yeoman takes the generation tasks.

grunt member
cowboy commented Dec 31, 2012

I feel like this discussion was really helpful and motivated a lot of positive change, so I'm closing it!

@cowboy cowboy closed this Dec 31, 2012
@shama shama referenced this issue in gruntjs/grunt-init Jan 14, 2013

Question: Grunt Init & Yeoman #31

grunt member

Where is the best place to discuss this issue going forward (prior to the transition)? Yeoman Issues, Grunt Issues, Google Groups or somewhere else? thx

grunt member

awesome, thx for the fast reply!

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.