More CLI options and pre-Gruntfile initialization through .gruntrc file(s).

[cowboy]

Ok, so I have this idea, and I think it's a good one.

I'd like to support .gruntrc files in projects / user home directories to allow per-project or per-user CLI option overrides. In addition, I want to add more CLI options to allow more configurability.

Note that items marked :new: are ones that don't exist yet, but probably should.

For a project

• Overriding --gruntfile to specify an alternate gruntfile name, like Gruntfile.coffee, so grunt doesn't have to guess.
• Overriding --base to specify an alternate base path.
• Overriding --pre-require to specify packages to be required before the Gruntfile is loaded. Eg. if --pre-require was coffee-script and --gruntfile was Gruntfile.coffee (or livescript per #841 or whatever), CoffeeScript wouldn't need to be hard-coded into grunt anymore (yay) :new:

For a user

• Overriding commonly-used options like --stack or --verbose or --no-color.
• Some way to specify user-tasks that don't really belong in a project's Gruntfile, but instead belong to a specific user's personal workflow. Like Growl notifications or always opening a browser when a web server task starts. These are probably less like tasks, and more like event listeners or hooks :new:

This doesn't exist yet, and might not exist until 0.5, but I want to do it.

What other CLI options should grunt have?

[sindresorhus]

:+1:, but make it .gruntrc.json so it gets syntax highlighting and opens in the correct app ;)

[wilmoore]

What other CLI options should grunt have? ...if --pre-require was coffee-script and --gruntfile was Gruntfile.coffee (or livescript per #841 or whatever), CoffeeScript wouldn't need to be hard-coded into grunt anymore (yay) :new:

Would the following be a fair workflow?:

1. npm install gruntfile-compiler-livescript --save-dev.
2. gruntfile-compiler-livescript is registered in project level .gruntrc.json as the handler for .ls files. Grunt would require this registered module (i.e. require('gruntfile-compiler-livescript')).
3. Use keyword gruntfile-compiler in package.json. This allows for easy searching in NPM.

.gruntrc.json

gruntfile: {
  compiler: {
    ls: 'gruntfile-handler-livescript'
  }
}

[h2non]

I prefer call it just like .gruntrc, adding extension to the filename is a bit dirty for hidden *UNIX files...

[wilmoore]

adding extension to the filename is a bit dirty for hidden *UNIX files

I don't think it's a problem. For example .tmux.conf doesn't seem to stand out too much although, I'm not sure what the .conf buys us in that case :). However, the .json suggested here will make a difference.

[h2non]

But if the file just support one type of data schema, in this case JSON, I think it's not necessary to specify the extension. However, if .gruntrc also can also support YAML format, I think it's okay to define the extension.

Just take a look to another specific configuration files from other node packages, like npmrc or bowerc, I prefer follow the conventions by the existent community

[wilmoore]

... like npmrc or bowerc

I'm not sure about bowerrc, but I do know that npmrc is a .ini type of format. With .gruntrc, we are talking about a file that will contain JSON (and as you mention, potentially YAML), so specifying either .json or .yml makes sense in terms of syntax highlighting.

For example:

• http://www.vim.org/scripts/script.php?script_id=1945
• http://www.vim.org/scripts/script.php?script_id=739

[misterjoshua]

I've implemented a workaround in lieu of a better thought out .gruntrc file or other method. I just make my Gruntfile.js call a local module named Gruntfile.local so that it has an opportunity to provide customizations at the right times. Gruntfile.local.js doesn't get committed:

• https://gist.github.com/anonymous/97677d5d96b8fe276b13

[shama]

All sounds okay except this part worries me:

Some way to specify user-tasks that don't really belong in a project's Gruntfile, but instead belong to a specific user's personal workflow. Like Growl notifications or always opening a browser when a web server task starts. These are probably less like tasks, and more like event listeners or hooks

I'm concerned about too much configuration existing outside of the local project and users will start creating global architectures and personalized installation steps. I understand the use cases suggested here are things very specific to the user but I'm just worried we're creating an avenue of misuse in exchange for a minor convenience.

Ideally it would be awesome if we could figure out a solution to the above use cases without needing a gruntrc file.

[misterjoshua]

I'd like to put forward the thought that perhaps giving the individual user too much power shouldn't be a consideration. It seems to run contrary to the idea of libre software; it may not be our place to say that users shouldn't be allowed to affect the behaviour of a Gruntfile, particularly when it runs afoul of the original author's intent for the script because it's entirely out of scope, as in the case of Growl notifications or overriding destination directories for copy tasks.

If it should be required for any specific software project that users not customize tasks, perhaps this could be addressed at the community level, and not by restricting what Grunt can do. Perhaps in support of this, as a part of the main Gruntfile, one might be allowed enable or disable grunt's capacity to load overrides and customizations from user-local or working copy-local Gruntfile modifications.

Emphasis on user-local or working copy-local, above, because I feel that there are most certainly circumstances where the distinction between a user's changes (to all Gruntfiles) and a working copy's changes (to one Gruntfile in a specific working copy for a project) is important.

[h2non]

Hi!

I created a simple helping utility to easily manage Grunt configuration in large projects, which adds support for a ini configuration file with specific options to pass to Grunt, like the future .gruntrc. Maybe it can be inspiring…

https://github.com/AdesisNetlife/croak/#configuration-file

[remcohaszing]

Grunt should follow the XDG basedir specification for the gruntrc file. This means the gruntrc file should be stored in $XDG_CONFIG_HOME/grunt/gruntrc. Optionally grunt might search this file in $HOME/.gruntrc if the one in $XDG_CONFIG_HOME/grunt/gruntrc does not exist.

[silkentrance]

+1 for supporting the XDG basedir specification as a first, and, as a fallback the standard $HOME variant. +1 also for naming it gruntrc.json or .gruntrc.json depending on the location where it is being stored. +1 also for having a man page for gruntrc.json as well :-)

When having a working copy local version of the gruntrc.conf file then that file should not be hidden.

Ultimately, multiple gruntrc.conf files should be merged using the following strategy:

• first the XDG gruntrc.json will be loaded
• second, the .gruntrc.json from $HOME will be merged in
• third, the working copy local gruntrc.json file will be merged in

[cowboy]

See https://github.com/gruntjs/grunt/pull/1368#issuecomment-182884660