grunt-usemin: Defining custom flow

Question

I am using grunt-usemin plugin. I wonder how to do below.

I have two blocks of usemin config in index.html.

<!-- build:js /scripts/scriptsmin.js -->
<script src="/scripts/jquery.min.js"></script>
...
...
<!-- endbuild -->

<!-- build:js /scripts/scripts.js -->
<script src="/scripts/app.js"></script>
....
...
<!-- endbuild --> 

First block, scriptsmin.js, is minified files. Second, scripts.js, contains all files which needs minification.

I like to.

1. run minifier (uglifyjs) on second block
2. concat first block with minified version of second (step 1)

Is it possible if these blocks are in the same file. I saw a section on flow. Couldn't follow whether I can name the block of configuration, and set seperate flow on each of it. It talks about flow based on file name (index.html). How should I write the grunt useminPrepare section.

Swallowtail

do you know if this is possible with the current version of grunt-usemin? – Broughton

Answer 1

I had the same problem. If you'll be satisfied with two files instead of one you can use a fork of usemin here. It enables few new flows, namely

• libs
• libs2min
• void
• remove

See full descriptions. So your html would be:

<!-- build:libs2min /scripts/scriptsmin.js -->
<script src="/scripts/jquery.js"></script>
...
...
<!-- endbuild -->

<!-- build:js /scripts/scripts.js -->
<script src="/scripts/app.js"></script>
....
...
<!-- endbuild --> 

Nesting the blocks isn't probably a good idea right now unfortunately. But you could try it out.

To install the fork instead of the regular grunt-usemin change your package.json as so

"devDependencies": {
    ...
    "grunt-usemin": "Rauno56/grunt-usemin",
    ...
},

and keep an eye on the main repo - maybe the feature isn't to far from getting there too.

Venesection

Answer 2

Just wondering why you need two separate targets for your JavaScript files, especially if they are going to be minified & concatenated into one file. What I would do is just have the one script block at the end of your file, like this:

<!-- build:js /scripts/scripts.js -->
<script src="/scripts/jquery.min.js"></script>
<script src="/scripts/app.js"></script>
<!-- endbuild -->

It's easier to understand like that, if all your JS is at one block rather than two. The useminPrepare is a task that basically updates your Gruntfile configuration to include concat, cssmin and uglify targets for your scripts and styles. Just run it on the files that have your build comments in, like so.

useminPrepare: {
    html: 'build/index.html'
}

usemin shouldn't look too different to useminPrepare, but what you may find you want to do is 'seed' useminPrepare with one file, if that contains the same build blocks as the rest of your HTML. So the actual usemin config could have a few more files in there:

usemin: {
    html: ['build/index.html', 'build/about.html', 'build/contact.html']
}

After useminPrepare runs, then run your concat, uglify and cssmin tasks, then finally run usemin. So you have a custom task like this:

grunt.registerTask('build', ['useminPrepare', 'concat', 'uglify', 'cssmin', 'usemin']);

Hope this helps.

Appointive

thanks for your help. The reason I have two blocks is, I keep the minified external libraries (jquery, angular, etc) intact, but just concat. I read it is best not to run the minifier again through well tested minified files. So I keep them all together in one block. Other files, like my custom js, needs to be minified, and then concat with others. so there is only one file to download. sorry being not clear about this. Do u think it make sense, and possible. thanks again – Swallowtail

jQuery is minified through Uglify (so that would see no difference), Angular through Google Closure (as near as makes no difference if compressed again with Uglify); Uglify itself is a battle-tested tool, if you see any problems with running minified files it might be best to report an issue, then again I use Uglify to minify everything that I load in, regardless if it was minified already (through RequireJS & the r.js optimiser), and have seen no problems. The only downside is obviously minifying more code takes more time, but I doubt if there are any bugs introduced by running min twice. – Appointive