feature: Optional configuration target

[corbanbrook]

In usemin 2.0.0 the configurations targets for all blocks are set to the 'generated' namespace. This makes it difficult to target individual blocks especially when using multiple of one type. Our current project is quite large and I like to keep my main source libs and vendor libs separated and use different uglify options on each js block, 1) to speed up build by not compressing/mangling concatenated vendor libs which come pre minified and 2) specifying preserveComments as many libs like JQuery include License comment banners which are required by copyright law (I know most people just strip these out anyways).

The included patch allows for including an optional configuration target in the html block like so:

    <!-- build:js:thirdparty assets/libs.js -->
    <script src="/lib/modernizr.js"></script>
    <script src="/components/jquery/jquery.min.js"></script>
    <script src="/components/underscore/underscore-min.js"></script>
    <!-- endbuild -->

    <!-- build:js:application assets/app.js -->
    <script src="/src/main.js"></script>
    <script src="/src/a.js"></script>
    <script src="/src/b.js"></script>
    <script src="/src/c.js"></script>
    <!-- endbuild -->

Now i rather than everything under the 'generated' target i have 'thirdparty' and 'application' and now I can easily specify custom uglify options for my vendor libs. Simple whitespace removal..

    uglify:
      thirdparty:
        options:
          compress: false
          mangle: false
          preserveComments: 'all'

I could even choose to exclude uglify of this js target altogether and only include 'uglify:application' in my build steps.

If you do not specify a target it will use the default 'generated'.

In the future it would be nice to take this a step further and allow for custom flows per target per type as well.

I welcome any feedback.

[corbanbrook]

Some good points are mentioned here: #219

Types could easily be inferred from the block and users could specify a config target, simply:

    <!-- build:thirdparty assets/libs.js -->
    ...
    <!-- endbuild -->

Users could explicitly configure the flow per target in useminPrepare, or use the default flow per type.

Correct me if I am wrong but currently it seems like a major restriction to keep flow and post processors restricted to type as you cannot have 2 blocks of the same type use a different configuration. Switching everything to use the user defined config targets would allow for ultimate flexibility while providing sensible defaults for those that do not wish to provide targets.

[szimek]

👍

I'm currently having an issue with grunt-angular-templates task that generates js file from html templates. To add the generated file to a specific file generated by useminPrepare (e.g. assets/app.js using the example above), I need to iterate over all file lists in concat:generated target to find the proper destination file. Having separate concat targets instead would simplify grunt-angular-templates configuration and implementation.

[jamesplease]

Any updates on this issue or issues like it? It seems like this problem has been brought up separately a number of times now, with a few different implementations that all work. If there's anything I can do to help something get implemented, just lemme know.

[sindresorhus]

@jmeas #313 (comment)