grunt
grunt copied to clipboard
gruntjs
public vs private tasks
Right now, all tasks are "public" meaning that all tasks can be run on the cli. It might be helpful on projects that have finely-crafted alias tasks to be able to make tasks "private" to hide them from the --help screen and prevent them from being run on the cli (or via lib)
It sounds like a fine idea, but since people usually need documentation to know what options or arguments a task can take, I doubt anyone will be running a task that they happen upon in the help screen if it wasn't documented somewhere else. But I could see it reducing clutter in the help output.
This is very usefull if you programmatically generate bulk tasks aliasses and targets or have destructive build chain sub targets. Like a clean task target that wipes all changes, it may not be triggerd from a broader grunt clean. Also in complex gruntfile the real config tasks mean nothing on their own but are just actions to refer in an alias and should be hidden for user.
This would be very helpful for task aliases (test in place of qunit with our own help message) and subtasks (test-report calls qunit_junit followed by qunit, so I'd like to hide the qunit ones in favor of test and test-report).
Just submitted https://github.com/gruntjs/grunt/pull/930 for review. The essence is simple if the task description is explicitly set to undefined then it would not show up in the grunt --help output.
+1
I like @opichals approach. And IMO people don't need documentation anymore (in most cases) if they are only presented with those tasks that are considered to be used by them. At the moment I include private at the beginning of each "private" tasks description. OK, but the help screen gets messy which it is not supposed to be.
Any progress on this one? I like the idea of prefixing tasks with an underscore to make them not show up on --help.
If tasks were private by default, we could override such with a new optional argument in grunt.registerTask:
grunt.registerTask("name", "description", {public:true}, function(){});
While this changes previous behaviour, it would prevent us from having to hide require()'d tasks.
Some IDEs already integrate with grunt and display a runable list of actions so some poor Joe with a Jetbrains IDE can compile and revert and shred all his work because of those wacky tasks we sometimes write and his curiosity he couldn't overcome. It's not really fictional..
So what's the problem with these two options? a) Tasks' description can either be a string or object b) 3rd optional object argument
In both cases the argument public: false or private: true will be available to set in ojbect.
For those who want to hide certain tasks included via registerNpmTasks and also other internal tasks, have a look over at for example vibejs-dynclass.
There, I am late binding the tasks that I do not want the user to see. Perhaps this could be a viable solution until grunt provides a similar feature of its own?
Note that the Gruntfile is still not finalized and needs additional work, however, late binding the external tasks and some internal tasks already works.
@rafi's comments about the IDEs are spot on; GUIs are now being built around grunt, so the need clean up the available tasks to the user is growing. I think the best approach to addressing this would be an option flag.
Aside from GUI considerations, some of our development teams include offshore devs, reducing the exposed tasks from the grunt CLI will help mitigate problems.
How about adding the following methods
lateBindNpmTasks which would load tasks prior to that a publicly exposed task, via registerTask or loadNpmTasks is invoked.
and
lateBindTask for internal tasks that would also be made available prior to that a publicly exposed task is invoked.
and
lateBindTasks for internal tasks...
Of course, other API methods such as renameTask would have to be changed as well, e.g. post pone unresolvable renames until all late bound tasks have been loaded.
The change should be minimal and would not affect any existing plugins nor gruntfiles.
@cowboy please have a look at my proposal towards late binding tasks using a suite of alternate API calls. Please note that renaming tasks is not possible with late bound tasks.
