Load task configs from multiple folders

I'm trying to make my grunt tasks (and thus the task configs) more modular with component.io, and was wondering if load-grunt-config can or could support loading the tasks from multiple folders.

With something like:

// glob
configPath: path.join(process.cwd(), 'components/**/*.js'),

or:

// array of folders or .js files
configPath: ['components/task1/concat.js', 'components/task2/uglify.js'],

Would something like that be at all attainable? I would have a separate function take care of this, but since configPath expects a single path there is not really a way to modify the behaviour without modifying the load-grunt-config source code.

In my opinion my proposed change would allow for an easier syntax for the override too, where you could just override the previous config like so:

// last config passed takes precedence
configs: ['components/concatdefault/concat.js', 'lib/concatoverride/concat.js'],

Quickly looking through the source code tells me that this could be possible. Any ideas on the best way to do this / possible downsides?

[jgallen23]

I've got this planned. You can do two right now with overrideConfig.

Cool! Really excited about this, I think it could make a big difference in modularizing grunt even more. Still learning my way around .js, otherwise I'd be happy to submit a PR (but maybe in the near future:).

[tawez]

Specifying files is more or less introducing a new convention.
I think that for the sake of simplicity we should avoid this.

My pull requests should resolve the issue.

overridePath accepts string and array of strings
This way we don't break backward compatibility.
Everything works as previous with except one can specify more than one override paths.

@tawez That's cool. I assume that it doesn't take glob syntax, right? Because even though this is a step in the right direction for what I'm trying to achieve, glob syntax would completely fix it. To clarify, what I'm trying to do is modularize my grunt tasks.

For example, if you wanted to install grunt-autoprefixer you would run:

npm i --save-dev grunt-autoprefixer && bower i --save preconfigured-autoprefixer

And bower would then install the configuration for autoprefixer. overridePath would know to look for folders in bower_components that identify themselves as grunt config files (with a prefix for example, grCfg-*/*.js).

This would mean considerably less time spent configuring grunt tasks. It's of course also possible to move the files by hand to ./grunt/, but I'd prefer to automate it. Also, I don't really understand what you meant by:

Specifying files is more or less introducing a new convention.

Could you clarify that?

[tawez]

@ismay My fix doesn't support glob syntax, so it resolves Your issue only partially.

I would like to wait for PR #81 before I'll make next step

Ok, cool.

[tawez]

What is loaded as config files is fixed inside /lib/readconfigdir.js.

/lib/readconfigdir.js (firstandthird:master):

var files = glob.sync('*.{js,json,yml,yaml,coffee,ls}', { cwd: dir });

load-grunt-config/lib/readconfigdir.js (Belelros:feature/62-parse-dir):

var files = parseDir(dir + '/' + '*.{js,json,yml,yaml,coffee,ls}');

I think that the only way to resolve your issue is to allow users to enter full path to the config file(s) using glob syntax.

I see two options:

1. Use glob syntax to specify files that will be loaded:

   path/to/the/files/*.{js,json,yml,yaml,coffee,ls}
   path/to/the/files/**/*.{js,json,yml,yaml,coffee,ls}
   path/to/the/files/grCfg-*/*.js
   

   Pros:

   • flexible

   Cons:

   • you need to specify all extensions that you need
   • more checking will be required in the code to guarantee that we are loading proper file
   • we will lose backward compatibility

2. Use partial glob syntax to specify files that will be loaded

   path/to/the/files/*
   path/to/the/files/**/*
   path/to/the/files/grCfg-*/*
   path/to/the/file
   path/to/the/file*
   

   Extensions should be added in /lib/readconfigdir.js (I assume that Swapping code with external library #81 is merged):

   var files = parseDir(dir + '.{js,json,yml,yaml,coffee,ls}');

   Pros:

   • still flexible (at the reasonable level)

   Cons:

   • path should end with * or file name without extension
   • we will lose backward compatibility

It is up to the maintainers if we will go this way.
In my opinion it's worth to do it, and the 2nd version sounds better for me.

@jgallen23 What do you think?

@tawez I'd agree that the second method sounds like the best way to go. And I'm interested in what @jgallen23 has to say as well, especially since this is a breaking change.

[damnedest]

@tawez second one is better I think.