Skip to content

Config grouping #140

@jeandat

Description

@jeandat

I think config grouping conception is bad. It is too much constraining and unusable as is. I explain.

With grunt there is a logical hierarchy:

  • task_name:
    • target1
    • target 2

The same is respected with load-grunt-config when you create one file per task except the task name is the filename. Good.

When using config grouping, you expect to put together several task configurations in one file in order to improve readability, comprehension et maintainability. So in that kind of file, you would expect to put together several task configurations like this:

lint-tasks.js

module.exports = function (grunt) {
    return {
        jshint: {},
        jsrc:{}
    };
};

I'm assuming every file is written in javascript but of course you could use yaml, …

You could have a css-tasks.js file for css tasks and another one for javascripts, another one for your tests with karma and protactor configuration for instance.

But it doesn't work like this.

With the actual conception, the filename must respect this pattern: <target>-tasks.js where <target> is the name that will be used as a task target for all tasks defined in the file. What it means is that all tasks in that file need to share a common target name.

So with our previous example, the lint-tasks.js file will generate a grunt config like that:

{
   jshint: { // task
        lint:{ // target}
    },
    jsrc:{ // task
        lint:{ // target}
    }
};

First, I don't see any added value and secondly, this is very constraining. Plus what about tasks that don't need a target ? I think it denatures grunt simplicity and model for no good reason.

It appears more clearly when you try to have several targets for the same task. You need to use an ugly hack that will concatenate the target part in your filename and the target part in your task name: cf. config grouping doc. For instance the entryjshint__test in lint-tasks.js will become the target lint_test in jshint configuration object.

Maybe I'm not seeing the whole picture but I guess it could be easier and more powerful by just allowing simple grouping of configuration without any magic like explained at the beginning.

I admit, I don't get why they need to share the same target name.

Thanks.

Just so you know, I love this plugin. I'm using it in my day-to-day job. Thanks a lot.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions