This is part of a larger discussion, but I have some pretty major concerns around tools like yeoman wrapping grunt.
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?
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.
Possible example of user confusion: yeoman/yeoman#484
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.
Related discussion happening in yeoman/yeoman#297.
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:
gotta run! ✈️
Sounds awesome congrats to @sindresorhus for the OSS gig 👍
❤️ ❤️ ❤️
This sounds really promising! Thanks for combining the efforts!
Proposal for future direction of Yeoman
Feedback please! :)
Revised proposal published to the mailinglist
Looks good to me ;0
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.
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.
I feel like this discussion was really helpful and motivated a lot of positive change, so I'm closing it!
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
awesome, thx for the fast reply!