You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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
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: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 entry
jshint__test
inlint-tasks.js
will become the targetlint_test
injshint
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.
The text was updated successfully, but these errors were encountered: