add #removeTask(identifier, [skipConfig])

[m90]

This adds the ability to remove a registered task from the gruntfile by specifying its identifier.

This will also remove the tasks configuration (with toggle) and its references in other tasks.

While this seemed handy when I started writing this I noticed that when done correctly this would also mean removing the task from all other tasks' configuration (which seems more or less impossible/too much work to me).

In case you still think this feature is a good idea one could at least think about adding automatic removal from

grunt.task.run(['taskToBeRemoved', 'otherTask']);

before merging this.

[bezoerb]

Hi @m90, i think removing tasks from the gruntfile could be very usefull for some kind of configurations. But without removing all references to the task configuration this could break someones build. Think for example of a build step like:

1. jshint
2. concat <%= jshint.target.dest %> 3 taskToBeRemoved <%= concat.target.dest %>
3. uglify <%= taskToBeRemoved.target.dest %>
4. copy <%= uglify.target.dest %> to final destination When you remove taskToBeRemoved for some reasons the whole build will fail. In this case you would have to consider references to the task config as well as references from the task config to do some sort of smart rewrite for uglify's src to concats dest.

I'll see if i can get some thoughts on this one and maybe we could work together on a good solution.

[m90]

That's exactly what I noticed half way through.

I'm pretty sure there's no rock solid way to fix every task configuration when removing a single task due to the plethora of possibilities.

I'll keep thinking about it though and let you know if something interesting pops up.

Cheers!

[mtpultz]

This may be completely out there since I don't know what would be involved. But if you could register your own task grunt.registerTask('setup', 'Some Kinda Setup', function() { .. } that was named the same as an existing config.task, but took precedence if setup was run. It could function like a hook, providing the option to jump over the task based on a return value??? or let it be handled by the developer whether the task is invoked or another is spawned instead. That would eliminate the need to remove the task, but also render it useless when invoked. It would be "sort of" similar to the functionality inheritance provides without the option to call parent::setup(). Is something like that even possible?

[mtpultz]

Another option that might be easier to implement is the ability to run tasks on the fly. I'm imagining something creative like:

// Based on grunt-copy-contrib grunt.config syntax
grunt.registerTask('createCopy', 'Create a copy', function(folderName) {

    var cwd = grunt.template.process("some/path/to/app");
    var src = grunt.template.process("some/path/to/src");
    var dest = grunt.template.process("some/path/to/dest") + folderName;

    grunt.task.run('copy: {  
       files: { 
          cwd: cwd,
          src: src,
          dest: dest
       }           
    }');
}

[bezoerb]

@mtpultz the 1st suggestion is nothing that could be implemented in this repo because this seems like this would be grunt core configuration. gruntfile-api gives just the possibility to programmatically change a gruntfile. Not to extend it with features that are not available in grunt itself.

for the second suggestion i think this should already be possible with the registerTask method. you can call it like this:

api.registerTask('createCopy', function(folderName) {
    var cwd = grunt.template.process("some/path/to/app");
    var src = grunt.template.process("some/path/to/src");
    var dest = grunt.template.process("some/path/to/dest") + folderName;
    grunt.task.run('...');
  })
}