Run all Grunt SubTasks except one - gruntjs

I've a bunch of subtasks for grunt watch (e.g. grunt watch:styles, grunt watch:sprites, etc). Then many other tasks run grunt watch. I would like to exclude one task. Is there a way to specify that? Basically run all grunt watch subtasks except grunt watch:dist.
I know I could create another task and only specify the subtasks I'm actually interested on, however, if I add another subtask later, that means now I've to add it, so I would rather not do it that way.
Thanks

There might be a better way, but this is doing the trick for now:
grunt.registerTask('watch:basic', function () {
delete grunt.config.data.watch.dist;
grunt.task.run('watch');
});
Fortunately, in this case, I don't have other tasks that might run grunt watch:dist, so it's safe to simply remove the config, but I can think of other cases where this approach would create conflicts.

Related

How to run the same grunt task with different configurations (programmatically)?

I've trawled the web for the last 2 hours trying to figure out how to do this so I'm asking here. I've read the documentation but I can't find a good example and I think I may be implementing some sort of anti-pattern or I have missed something very basic but here goes.
I want to loop around an array and perform this task in each loop
grunt.task.run('string-replace:dist');
However, every time I run this loop I need a slightly different config. Different output folder, different replacement array etc etc
I have been changing the config like this.
grunt.config.set('string-replace.dist.options.replacements', translationsArray);
grunt.config.set('string-replace.dist.files.0.dest', 'dist/' + langCode + '/');
Here comes the problem. Grunt does not seem to execute tasks, wait for them to finish and then continue with your code. So it sets up the task for each loop but does not run it, then it changes the config for each loop overwriting the old config each time. Then it runs all the tasks with the last config. I just want to make Grunt execute the task, wait till its done, change the config, rinse and repeat.
Am I doing something really stupid? Grunt documentation seems to be desperately telling me its synchronous but this does not seem to be the case with grunt.task.run. I would also like to point out that I don't want to just register more tasks with the different options because I don't know how many times I might have to run this loop. It is controlled from elsewhere so it can be dynamic and data driven. Unless I'm supposed to register tasks dynamically?

Uglify directly or concat and uglify

I am using grunt to build my JS project. I see that the uglify plugin for grunt is capable of merging multiple JS files into a single file and uglify them. Given this feature, I am wondering if there is a need to use concat plugin at all. Can I directly use uglify. Is there something that i am missing.
Most tutorials seem to suggest that I must first use concat then uglify.
You don't need a separate concat tool. See the docs (under "Usage examples - Basic compression"). You just specify the files you want uglified, and it will concatenate them for you.

passing argument between grunt task

I run a grunt task which calculates some stuff and puts the result in a variable. Later I want to use this result in another grunt task. I tried a lot of things to share this result between this two tasks but I did not succeed.
Have you got any idea how to do this?
finally I found a good solution,
I use grunt.config
In the task which is calculate the result I had
grunt.config.set('result', result)
And I can access it in other task with
grunt.config('result')

How can I remove all color information from Grunt output?

I'm a little new to Grunt and am using it in our automated build system (on Windows). When running Grunt manually in the console, the coloring is extremely helpful. However, when running it in an automated setup, it results in color information in the build log, like this:
[4mRunning "sass:all" (sass) task [24m
The extra characters decrease the readability of the build log and I'd like to get rid of them.
I'm aware of the grunt.log.uncolor method for individual strings, but I'm wondering if there's a way to configure Grunt to output all logs without color information or if there's an existing plugin to do this. If not, I'll likely write my own plugin.
I feel like this would be a common occurrence — using Grunt in an automated system where you'd want to read the build log as plain text — so maybe I'm just missing something.
Of course, I finally find the answer right after asking the question...
Use the simple command-line option --no-color.
I was scouring the API but somehow missed the "Using the CLI" section of the documentation.

Grunt Speed: Directly Specifying Tasks vs Combining

With Grunt, when you are registering tasks, how much slower is it to use tasks you already registered, maybe with several subtasks of their own, versus using tasks straight from initConfig, or even writing the functions by hand in the registration? Here's an example:
How much slower would specifying grunt minify from the command line be here:
grunt.registerTask('minify', ['preprocessed', 'nonprocessed']);
gruntregisterTask('preprocessed', ['sass:convert', 'haml:convert']);
grunt.registerTask('nonprocessed', ['uglify', 'cssmin', 'htmlmin', 'phpmin']);
than if you created the minify task like this:
grunt.registerTask('minify', ['sass:convert', 'haml:convert', 'uglify', 'cssmin', 'htmlmin', 'phpmin']);
I have to believe there is at least some slowdown, as Grunt has to go through more steps to "see" the tasks at each level of abstraction, but I just want to know if it's something to worry about only with thousands of modules, tens of sub-tasks per task, etc. or if it'll affect smaller projects as well.
You can test this yourself by using time-grunt.
// Gruntfile.js
module.exports = function (grunt) {
// require it at the top and pass in the grunt instance
require('time-grunt')(grunt);
grunt.initConfig();
}
Personally I've never noticed any speed decrease by specifying more aliases rather than less, and if there is slowdown it'll be in milliseconds. It'd be interesting to see a full test suite though.

Resources