Needlessly complicated design

[ProLoser]

So as someone who's new to grunt (and tried working off a boilerplate such as yeoman-angular) I find this grunt plugin to be ridiculously complicated and problematic.

One of the big annoyances is that it's a bottleneck for a lot of other operations, primarily it is a means to parse the HTML file for a listing of assets.

If I want to do something like using this listing for other tasks I am forced to fork the plugin and create new libs.

So NOW instead of learning just the Grunt API I have to learn the Usemin API

You have no idea how unbelievably frustrating this is. It also makes no sense that in the completely modular world of grunt tasks, THIS task (which is being distributed as if it's a prominent and well-architected plugin) requires you to create sub-tasks.

What happens if I want to compile coffeescript? What about LESS? What about SASS? What if I want to have these compilers do the concatenation.

I must now create more libs for this plugin. It's just a HUGE PITA.

I've instead resorted to grunt-dom-munger which proved to be FAR less complicated, FAR easier to use with other tasks, and no confusing 'automagic' or 'api' to learn on top of your typical grunt.

I would really like to see this library be designed differently, or at least stop distributing it as a defacto solution with yeoman packages. There is such a small chance that people would want to use this grunt configuration (unchanged) and it's only made MORE painful for people who aren't starting a project from scratch but trying instead to integrate with an existing project.

I would prefer to see an API where I can simply use <%= usemin.prepare.vendor-js %> or access it in a function I can define on my grunt tasks (to update their configurations) instead of the current implementation.

Seriously, Yeoman is supposed to make people trying to adopt grunt EASIER, not MORE COMPLICATED.

[silvenon]

I agree, it is a bit difficult at first and the plugin itself is a bit unpolished. I think this plugin is comprised of subtasks because it's a real pain doing all those subtasks manually.

Once you figure out how the plugin works, it's very cool. If you want to concatenate and compress stylesheets with Sass, LESS or Stylus, you don't, you let grunt-usemin do it.

Can you give me an example where it's really inconvenient to use grunt-usemin?

[jcontonio]

I think the documentation could better explain the paths in the build comments in your html. How to deal with common issues like Wordpress templates, or apps that have complicated directory structures.

I have to alias /js, /css, and /img in my vhost file because usemin will not keep my absolute paths to image assets, javascript files, and css files (like /content/themes/something/img). Also, it doesn't find images in php files for the filerev, so I can't filerev my images. It's not inconvenient, but it could use some love for sure. I wish I could devote some to it.

[silvenon]

Also, generator-webapp commented out the grunt-usemin alternative, so you can just remove the plugin and uncomment those concat, uglify etc.

[sindresorhus]

@ProLoser I absolutely agree. It's grown out of hand. Mostly because of various convoluted needs through its life and not enough TLC. We would be happy to deprecate this task if anyone comes up with something better that solves the use-case.

A braindump of requirements here: http://oksoclap.com/p/usemin-rewrite