-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Multitask option to set the default behavior when a subtask is not specified #815
Comments
👍 This would also be helpful when you have a bunch of subtasks for |
👍 |
I have a case where I'd like to have some additional watch targets for specific deployment targets, but I'd like the generic watch task not to run any of them, and an option like the one described by @dylang would be very useful. |
+1 |
I agree, I actually thought this was the default behavior when I first started using grunt, it just made sense. grunt.initConfig({
myMultiTask: {
options: {
clean: true,
dir: ""
},
defaults: {
clean: false.
dir: "foo"
},
bamboo: {
dir: "bar"
},
jenkins: {
dir: "baz"
}
}
}); Invoke:
@cowboy: Does this make any sense or are there perhaps any plans on a different approach that enables one to run this without having to define a new task that runs a specific subtask? |
👍 Having the exact same situation with |
+1 for default subtask |
👍 |
I don't like the idea of a named option, because it will 1. override any existing task's This problem could be solved with another reserved key next to the Another possible solution: Right now, properties starting with Here's a sample Gruntfile: module.exports = function(grunt) {
grunt.initConfig({
foo: {
a: {},
b: {},
_c: {},
}
});
grunt.registerMultiTask('foo', function() {
console.log(this.nameArgs);
});
}; And some sample CLI output.
Note that in the current Grunt, running |
I love the underscore option. It maps to the way partials work in Sass, in Nate Eagle On Jan 22, 2014, at 3:12 PM, Ben Alman notifications@github.com wrote: I don't like the idea of a named option, because it will 1. override any This problem could be solved with another reserved key next to the Another possible solution: Right now, properties starting with _ are Here's a sample Gruntfile: module.exports = function(grunt) { grunt.registerMultiTask('foo', function() { And some CLI output. $ grunt foo Running "foo:b" (foo) task Done, without errors. $ grunt foo:_c Done, without errors. It's just a thought, for now at least. — |
@cowboy how would |
I like using "default" as an extra keyword. Though that could break code in the wild I guess. The next question is whether the value should be a string that references the default task or just be the task object itself. I suppose it could be both dependant on the type the user uses. |
+1 for default target. I'm using a build task that has several targets, named 'package1' to 'packageN'. Running the build task without a target would build a lot of the modules more than once. Being able to flag this target would be exactly what i need. The underscore option is fine, but in my situation it would lead to the use of a lot of underscore target names (_packageX) - which seems awkward. |
👍 A default target is needed and makes sense. |
+1 Here's a dirty hack until something more official comes along. Create a file (tasks/multitask-default.js) and call grunt.loadTasks('tasks') in your Gruntfile.js. Use this for the contents of the file:
|
👍 grunt.initConfig({
myMultiTask: {
defaultTarget: 'jenkins',
options: {
clean: true,
dir: ""
},
bamboo: {
dir: "bar"
},
jenkins: {
dir: "baz"
}
}
});
|
I like the * designation to make it explicit that you want to run all of the tasks, too. |
+1 I would like to write independent grunt-exec tasks, where only the specified subtask runs by default, similar to how a traditional Makefile behaves. |
+1 for default subtask. |
👍 This would be a great feature. |
Hi, I have the following scenario: My app is built for multiple clients, so I'm setting up grunt to handle commands like: Gruntfile.js
Any ideas to accomplish what I want? |
+1 for the defaultTarget
|
👍 Would solve some problems we are having really nicely |
+1 for defaultTarget Especially in the case of multiple watch targets this would be really helpful. |
It's easy to overcome this limitation by monkeypatching: module.exports = (grunt) ->
grunt.registerMultiTask 'test', 'Docs...', ->
...
decoratedFn = grunt.task._tasks['test'].fn
decorator = (target) ->
args = grunt.util.toArray(arguments)
if not target
args = ['all'].concat(args.slice(1)) # running just 'grunt test'
else if not grunt.config(['test', target])
args = ['arbitrary', target].concat(args.slice(1)) # running arbitrary test, e.g. 'grunt:test/my-specific-test-file.coffee'
@nameArgs = "test:#{args[0]}"
decoratedFn.apply(@, args)
grunt.task._tasks['test'].fn = decorator
Config:
Now I'm able to do:
|
+1 This would be a useful feature. |
How come this is still not a thing? |
Sometimes it's dangerous or undesired to run all of a multitask's subtasks by default.
Proposal: an option to set the default behavior when a subtask is not specified instead of iterating through all the subtasks.
Default
deploy
to usedev
when a subtask is not specified:Example:
Don't run any bump subtasks if the subtask is not specified.
The text was updated successfully, but these errors were encountered: