Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Config grouping #140

Open
jeandat opened this issue Nov 12, 2015 · 1 comment
Open

Config grouping #140

jeandat opened this issue Nov 12, 2015 · 1 comment

Comments

@jeandat
Copy link

jeandat commented Nov 12, 2015

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.

@easingthemes
Copy link

Grouping is very useful.
eg: target-tasks.js

...
var config = {};

for (var i = 0; i < arr.length; i++) {

    config['task__' + i] = {
        options: {
            option: 'something-' + i,
            files: [
                arr[i]
            ]
        }
    };

}

return config;

will create dynamic targets with dynamic config

task: {
    target_0: ...,
    target_1: ...,
    ...
}

Only missing part here is possibility to create global config for parent task which is not related to targets.
eg:

task: {
    parentConfig: {},
    target_0: ...,
    target_1: ...,
    ...
}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants