A modular approach for grunt configuration. Forget about your Gruntfile.

[endel]

Hey guys,

 

I'm here asking for your thoughts about a new way to configure your Gruntfile. 

http://endel.github.io/grunt-loader/

 

I think we have pros and cons about this approach:

 

Pros:

• Readable syntax
• Configure the Gruntfile once
• Easy to copy/paste modules between other projects
• Better versioning of each module

Cons:

• Need to "translate" JSON configurations into YAML.
• It's not the default way that Gruntfile works, which obviously isn't cool

Please let me know your thoughts about it.

[codingcampbell]

I'm a little confused by the premise. Gruntfiles are not JSON. One of the great things about Grunt is that it's basically "Makefile" that uses the Node ecosystem.

 

So if I'm registering custom tasks that execute JavaScript, I don't really see how that could ever translate to YAML. I guess this expects me to keep my executable tasks in the existing Gruntfile and reference that from the YAML config?

 

I'm not really clear why I would augment my Gruntfile with this. YAML is better than JSON (comments, yay!) but that advantage does not really exist over JS.

 

Edit: In my case I think I would sooner use a CoffeeScript version of Gruntfile. Readability gain + no extra files.

[Evan Burchard]

I like npm because it does a good job at getting me node packages.  I don't want a grunt task manager as much as I want grunt tasks.  If you emphasize those more, I'd be all over this.

 

I kind of like the idea of splitting it out into separate files because it makes tasks/ideas discoverable.  The syntax itself is a wash at best for me, and it means more maintenance for you.  Learning a new syntax for creating gruntfiles is not interesting to me, but discovering and easily importing tasks is.  A whole system like Yeoman or Bower has is probably overkill, but up to date examples of (many many) grunt tasks would be cool to include. 

 

It could even have a preprocessor for the grunt file.  Then someone could potentially just rely on your system to import from the examples directory or create their own.  That would address both of your cons (but maybe introduce a few more).