Global usemin disable target

[dlmiles]

It would be very useful to disable usemin completely with a setting like:

  options: { disable:true }

Without needed to completely reconfigure Gruntfile.js to come up with a new rule scheme to perform the following tasks that are still useful.

Enabling the disable:true option would still configure concat/uglify/cssmin but would setup a pass-through mode. usemin will still however resolve and fix as necessary relative paths like:

  <!-- build:js ../scripts/vendor/modernizr.js -->
  <script src="../bower_components/modernizr/modernizr.js"></script>
  <!-- endbuild -->

In the above example usemin would:

• Ignore the target path "../scripts/vendor/modernizr.js" set in the HTML comment
• Transform the src="" attribute by removing the relative component outside the tree of the target directory the HTML file is in. So this means removal of "../bower_components/" part. It should check based on the build:js file type (js in this case), make a new output path: "js/modernizr/modernizr.js" using the remaining. If really necessary to ensure path uniqueness "js/usemin-disabled/modernizr/modernizr.js" and error on any duplicate paths created in processing.
• Configure "concat" to basically file copy, from the source location to the new location of a single file at a time, nothing is concatentated.
• Configure "uglify" to do nothing.
• Configure "cssmin" to do nothing.
• The final pass of "usemin" will only edit the src="" locations, and remove the 2 HTML comment markers. It does not replace the multiple HTML elements with a single (concatentated element), it only correct the src="" attribute to the new path now inside the project of the copied file.

This allows an easy way at the flick of a switch to not transform anything, but still fixup and populate all JS and CSS assets from outside the tree.

This facilitated development/debugging where the goal is easy to read source code in the original distribution layouts and filenames, using verbatim copies. Where we do not care about download overhead or hits to server performance concerns. Since we are developing.

Then to go back to production testing / releasing we flick the switch and retest using minimized copies.

[dlmiles]

To anyone wanting this, here is a hacky way to get something similar (without tearing up your Gruntfile):

Remove the targets: useminPrepare, concat:generated, ugilify:generated, cssmin:generated, filerev, usemin

Add https://github.com/cgross/grunt-dom-munger as a task. Configure like:

        dom_munger: {
            "www/index.html": {
                options: {
                    prefix: [
                        {selector: 'link', attribute: 'href', value:'bower_components/'},
                        {selector: 'script', attribute: 'src', value:'bower_components/'}
                    ]
                },
                src: 'src/index.html',
                dest: 'www/index.html'
            }
        },
        copy: {
            bower_components: {
                expand: true,
                src: ['bower_components/**/*.js', 'bower_components/**/*.css'],
                dest: 'www/'
            }
        },

Now add a copy:bower_components task that copies the entire bower_components tree into the published output folder (this is "www/" for me, but is often also "dist/". You can copy only the things you use but, this is just for development mode right. Maybe some peoples trees will be huge.

This will transform:

 <!-- build:js ../scripts/vendor/modernizr.js -->
  <script src="../bower_components/modernizr/modernizr.js"></script>
  <!-- endbuild -->

INTO

 <!-- build:js ../scripts/vendor/modernizr.js -->
  <script src="bower_components/../bower_components/modernizr/modernizr.js"></script>
  <!-- endbuild -->

Which now resolves to a copied file.
Like I say a hacky workaround.

[stephanebachelier]

I think it's related to #456.

I already use this in project but with two build phases. One which does all the optimization, and another one which does not go through the usemin process, which provide a non-minified build. In my use case, the choice of the build is made by using a CLI option.

I use the two different phases approach because I use RequireJS which is not supported anymore by usemin: RequireJS block are not supported. So in the end you will still have to use a different phase for the build if using RequireJS.

[stephanebachelier]

@dlmiles it should be covered by #487. Marked as a duplicate.

This should be opened until we merged #487 and document your use case.

[stephanebachelier]

@dlmiles I close it in favor of #487 and #456.