Review how configuration groups are handled

[dfernandez79]

I run into the same problem fixed by https://github.com/firstandthird/load-grunt-config/commit/5c64e847a7604da8cc546389b455e44443fd1326, to realise that the way in which configuration groups is handled is not useful to me.

Right now each task in xyz-tasks is translated to task:xyz, but what happens when you have multiple task configurations in your group?

For example, I've a build like this:

docs-tasks.coffee

module.exports = (grunt) ->
   copy:
      targetA:
          # src and dest for targetA
      targetB:
         # src and dest for targetB

The problem is that the default task group behavior will generate:

copy:
    docs:
         targetA:
         targetB:

Which is incorrect. I know that this is how the library defines the handling of config groups, my argument is that the current way of handling groups is not very useful.

Probably you'll ask why I have two copy configurations instead of using multiple file patterns... the problem is that I'm using the process function to transform some files, and I cannot pass that function in a pattern, so I'm forced to use multiple configs. But the copy task is irrelevant, I also have configurations like that for the watch task, because it allows me to reduce the number of tasks executed when something changes, for example:

watch:
    styles: files: groupA tasks: styleProcessTasks
    jade: files: groupB tasks: jadeCompiler

[jgallen23]

The point of the config groupings is to group your config into sections. For example, I would have a styles-tasks.yaml and a jade-tasks.yaml and each of those would have a watch task.

As far as the copy task goes, you could always just have a copy.yaml in your grunt directory that will allow you to define as many task targets as you need.

[jgallen23]

I'm going to close this. Please reopen if you can think of a better way to handle the config groups.