Coder Social home page Coder Social logo

grunt-concurrent's Introduction

grunt-concurrent

Run grunt tasks concurrently

Running slow tasks like Coffee and Sass concurrently can potentially improve your build time significantly. This task is also useful if you need to run multiple blocking tasks like nodemon and watch at once.

Install

npm install --save-dev grunt-concurrent

Usage

require('load-grunt-tasks')(grunt);

grunt.initConfig({
	concurrent: {
		target1: ['coffee', 'sass'],
		target2: ['jshint', 'mocha']
	}
});

// Tasks of target1 run concurrently, after they all finished, tasks of target2 run concurrently, instead of target1 and target2 running concurrently.
grunt.registerTask('default', ['concurrent:target1', 'concurrent:target2']);

Sequential tasks in concurrent target

grunt.initConfig({
	concurrent: {
		target: [['jshint', 'coffee'], 'sass']
	}
});

Now jshint will always be done before coffee and sass runs independent of both of them.

Options

limit

Type: number
Default: Twice the number of CPU cores with a minimum of 2

Limit how many tasks that are run concurrently.

logConcurrentOutput

Type: boolean
Default: false

You can optionally log the output of your concurrent tasks by specifying the logConcurrentOutput option. Here is an example config which runs grunt-nodemon to launch and monitor a node server and grunt-contrib-watch to watch for asset changes all in one terminal tab:

grunt.initConfig({
	concurrent: {
		target: {
			tasks: ['nodemon', 'watch'],
			options: {
				logConcurrentOutput: true
			}
		}
	}
});

grunt.loadNpmTasks('grunt-concurrent');
grunt.registerTask('default', ['concurrent:target']);

The output will be messy when combining certain tasks. This option is best used with tasks that don't exit like watch and nodemon to monitor the output of long-running concurrent tasks.

indent

Type: boolean
Default: true

You can optionally skip indenting the log output of your concurrent tasks by specifying false. This can be useful for running tasks in parallel for a stdout parser which expects no indentation, for example, TeamCity tests.

grunt-concurrent's People

Contributors

arthurvr avatar baer avatar chriswren avatar diogoriba avatar fatfisz avatar jimf avatar kerrychen95 avatar kimjoar avatar mbuchetics avatar richienb avatar shingyx avatar sindresorhus avatar wkwiatek avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

grunt-concurrent's Issues

Setting task options doesn't works

Hello. I have concat task in my Gruntfile.js and I set its options dynamically:

    grunt.initConfig({
        concurrent: {
            // some tasks
            build: [
                // some subtasks
                'concat:frontofficeCommonScripts'
            ]
        },
        concat: {
            frontofficeCommonScripts: {
                src: [
                    // some files
                ],
                dest: someDest
            },
            // some other subtasks
        },
        // some other tasks
    });

    grunt.registerTask('development', function () {
        grunt.config.set('concat.options.sourceMap', true);

        grunt.task.run(
            // some tasks
            'concurrent:build'
        );
    });

When I trying to run development task source map is not created, also --verbose shows during building:

Options: separator="\n", banner="", footer="", stripBanners=false, process=false, sourceMap=false, sourceMapName=undefined, sourceMapStyle="embed"

Same development task runned without concurrent creates source map fine.
How can I fix this or it is a bug?

Concurrent only runs first task on node v0.10.20

I thought I was cursed when, all of the sudden, concurrent stopped working altogether while working on CLEAN, my fork of MEAN.

Finally, I returned to the last PC in which it ran OK and, sure enough, it has node v0.10.5 installed.

I have heard it works as far as v0.10.15. Will try it now and report.

Gruntfile is really simple:

grunt.initConfig
  watch:
    public:
      files: ['public/**']
      options:
        livereload: true

  mochaTest:
    main:
      options:
        reporter: 'spec'
      src: ['test/**/*.coffee']

  nodemon:
    main:
      options:
        file: 'server.coffee'
        ignoredFiles: ['node_modules/**', '.idea/**', 'public/**', '.git/**']
        debug: true
        delayTime: 1

  concurrent:
    main:
      tasks: ['watch', 'nodemon']
      options:
        logConcurrentOutput: true

Ah, yes, I tried changing the tasks' order (watch and nodemon) to no avail.

Passing runtime configuration to spawned tasks

Here goes my Gruntfile. What I am trying to do is having build task that just creates production build and exits. Next to it I want to have dev tasks that is supposed to run some watchers and connect server.

grunt.registerTask('dev', function() {
    grunt.config.set('browserify.main.options.watch', true);
    grunt.task.run(['concurrent']);
});
grunt.registerTask('build', ['browserify']);

grunt.initConfig({
    browserify: {
        files: {'public/main.js': ['src/main.coffee']}
    },
    concurrent: { main: ['browserify', 'watch', 'connect'] }
});

After some headache I had realized that browserify task is executed in separated process thus it loads the Gruntfile on its own and doesn't see that dynamically set option for 'watch' in browserify. Is there some shared object I could use to pass around information that I am running in dev mode ?

Concurrent is not running the tasks registered inside other task

In one of my Grunt tasks I'm dynamically registering several tasks depending on the number of CPU Cores that the system has. After those tasks are created, I can successfully run them using grunt.task.run() . But when I try to run them using concurrent the error "Warning: Task not found. Use --force to continue.".

Readme change, Yeoman inclusion

I think the README might have a typo. I think it should read:

  concurrent: {
    target: {
      tasks: ['nodemon', 'watch'],
      options: {
        logConcurrentOutput: true
      }
    }
  }

Otherwise no meaningful output is logged to console for me.

Also, since you're on the yeoman team, I thought you might want to know that 1.0 beta with yo webapp writes grunt-concurrent into package.json as a dependency for ~0.1.0, which doesn't seem to be compatible with this feature.

Can't context my tasks

With your task, I can't know where I am.

For instance, I do var taskName = grunt.cli.tasks[0] or process.argv[2] to know if I start "dist" or "dev" mode, but everytime a concurrent task is started, taskName is changed by "scripts" or "styles" so I never know where I am.

For example, I use to use that: if(taskName === 'dist') { scripts = 'uglify';} else { scripts = 'concat' };

With your way, I can't because taskName will be called the name of the task started by concurrent.

I don't know if I'm clear, please let me know.

How is possible to run the ionic:serve and watch with concurrent?

Allow running certain tasks sequentially

My current setup looks like this:

concurrent: {
    options: {
        logConcurrentOutput: true
    },
    dev: {
        tasks: ['nodemon:dev', 'node-inspector', 'watch:less', 'watch:jshint', 'watch:nunjucks', 'watch:uglify'],
    }
},

However, I need watch:uglify to run after watch:nunjucks. AFAIK, this is not supported. I propose the following syntax to allow it:

tasks: ['nodemon:dev', 'node-inspector', 'watch:less', 'watch:jshint', ['watch:nunjucks', 'watch:uglify']],

Edit: This was problematic because I had the watch option atBegin set to true so that I could have all my stuff build concurrently when the server is fired up. Setting this to false and running nunjucks once before starting concurrent works around this issue, as those two watches should naturally fire sequentially, since one will trigger the other. This comes at a slight startup cost, but I guess we can work around that by creating a 2nd concurrent task:

concurrent: {
    options: {
        logConcurrentOutput: true
    },
    serve: {
        tasks: ['nodemon:dev', 'node-inspector', 'watch:less', 'watch:jshint', 'watch:nunjucks', 'watch:uglify'],
    },
    ugless: {
        tasks: ['uglify','less']
    }
},

grunt.registerTask('default', ['clean','nunjucks','concurrent:ugless','concurrent:serve']);

--no-color

grunt-concurrent colorizes the output although I start grunt with the --no-color option. The reason why I use this option is because the console in sublime text doesn't support colorized output. It would be great to have that feature!

Add option to run all tasks and marshal failures until final report?

It would be powerful if we can force grunt-concurrent to run all specified tasks and instead of bailing on the first failing test it would save the status and continue running all the other tasks.

Then when they are all done it would see if there were any failures, and if so fail the whole batch.

This would allow to run a batch of parallel builds (and tests) and still see results of all of them, instead of only up-to the first failing one.

I think ideally it would marshal failing tasks logs and output them all at once at the end (the successful ones would still be reported directly on completion): this would group all the failures for easy review if you scroll up in the log (which is convenient if you have many tasks with long output).

What do you think? I feel it should be in here instead of a whole new plugin.

Loading npm tasks that concurrent uses

Not really an issue, but a question.

Is there a way to load the tasks that concurrent needs inside the task that is being run?

So I would like to do this:

concurrent: {
    protractor: ['protractor:safari', 'protractor:firefox', 'protractor:chrome']
}

grunt.registerTask('teste2e', [], function() {
    grunt.loadNpmTasks('grunt-concurrent');
    grunt.loadNpmTasks('grunt-protractor-runner');
    grunt.task.run('concurrent:protractor');
});

But the protractor is not reachable inside the concurrent task.

This can be fixed by moving the grunt.loadNpmTasks('grunt-protractor-runner'); outside of the registerTask('teste2e'). But then it would get loaded every time I run any grunt task, and that's what I'm trying to avoid.

Is there a way to load that task only in the teste2e -task?

No output with 2 tasks.

Hi,

I have this inside my Gruntfile: http://pastebin.com/sFbVCB53

After this I call this:
grunt.registerTask("stats", ["concurrent:stats"]);

And when I call grunt stats, I only see the output from one task, maybe from this task which executes faster as the other one.

Regards

Chris

Concurrent is not working with grunt-newer

Closed: Problem is my grunt file not this plugin

It looks like concurrent doesn't seem to be able to work with grunt-newer

Warning: Running "compile:css" task
    Warning: Task "newer:copy:scss" not found. Use --force to continue.

grunt.registerTask('compile:css', function() {
        grunt.task.run([
            'newer:copy:scss',
            'newer:preprocess:scss',
            'newer:csscomb:scss',
            'sass',
            'colorguard',
            'autoprefixer',
            'px_to_rem',
            'cssmin',
            'notify:sass'
        ]);
    });

config.sassjs = [
            'compile:css',
            'compile:js'
        ];

Is there an easy way to remove the blank lines from the output?

I am running concurrent mocha , and the output like this:

Running "env:chrome" (env) task

Running "simplemocha:sauce" (simplemocha) task


  tutorial (chrome)
    ✓ should get home page (2875ms)
    ✓ should go to the doc page (0) (2737ms)
    ✓ should return to the home page(0) (2450ms)
    ✓ should go to the doc page (1) (2462ms)
    ✓ should return to the home page(1) (2548ms)


  5 passing (20s)


Done, without errors.

becomes something like this:

  Running "env:explorer" (env) task

    Running "simplemocha:sauce" (simplemocha) task


      tutorial (internet explorer)

        ✓ should get home page (2930ms)

        ✓ should go to the doc page (0) (3120ms)

        ✓ should return to the home page(0) (3381ms)

        ✓ should go to the doc page (1) (3051ms)

        ✓ should return to the home page(1) (3949ms)


      5 passing (28s)


    Done, without errors.

Just wondering why the extra white lines and how to get rid of them?

Limit option

Hey i was wondering, why the limit option? Is there any performance issue that made you set this limit?

And by the way, now this task stopped working

Warning: Object #<Object> has no methos 'eachLimit' use --force to continue

Fail fast deactivation

I have a CPU intensive task (task1) and a Network intensive task (task2), which I want to run in parallel. Now, if task1 fails, task2 is killed. The issue is that task2 has to clean after itself and it does not get the chance.

Is there an option to:

  • Either let all tasks fully complete their job (preferred and easier)
  • Or have some sort of finally clause

I am happy to try open a pull request if any of the choices are part of the philosophy of the library.

Concurrent task keeps running even though grunt shuts down

I have a fairly elaborate setup in which some tasks are running concurrently and starting up external processes (with grunt-shell). When one of those external processes errors out grunt shuts down (as it should), but the concurrent:server task seems to keep on running, because when I try to run my tasks again, I get a

Fatal error: Port 9000 is already in use by another process.

error thrown.
Is there some way to tell the concurrent:server task to die along with grunt?
I took a thorough look through the API docs, but didn't find anything useful.

I wasn't sure whether to post this here or on grunt, so I'm doing both:
gruntjs/grunt#827
Sorry if this isn't the right place.

2.0.0 indentation compatibility issue with karma "dots" reporter

Not sure if this is an issue here, or simply an interoperability issue with the way the karma "dots" reporter is implemented, but it appears that after upgrading from 1.0.1 to 2.0.0, I'm seeing the indentation whitespace interspersed between the dots coming from the karma "dots" reporter.

Before:
screen shot 2015-07-14 at 2 57 02 pm

After:
screen shot 2015-07-14 at 2 57 42 pm

Tasks run in alphabetical order, not the order of the gruntfile

Hi,

There appears to be a bug where grunt-concurrent messes up the execution order of a task. For example, I have this setup:

    concurrent: {
        all: {
            tasks: [
                'concurrent:processJs',
                'concurrent:splitGlobal',
                'concurrent:splitAndWrapLegacy'
            ],
            options: {
                limit: 4,
                //logConcurrentOutput: true
            }
        },
        splitGlobal: [
            'csssplit:global',
        ],
        splitAndWrapLegacy: [
            'css_wrap:legacy',
            'concat:legacyAndLegacyExtra',
            'csssplit:legacy'
        ],
        processJs: [
            'concat:globalJsAngular',
            'concat:globalJsComponents',
            'concat:globalJs',
            'copy:srcJsToTmp',
            'uglify:globalJs',
            'concat:globalJsMin',
            'concat:audiApp',
            'uglify:globalApps',
        ]
    },

When I run all three of these tasks concurrently by running concurrent:all, I notice the processJs task executes in this order (I have trimmed the console output):

Running "concurrent:processJs" (concurrent) task

    Running "copy:srcJsToTmp" (copy) task          
    Running "concat:globalJsComponents" (concat) task
    Running "concat:audiApp" (concat) task
    Running "concat:globalJsAngular" (concat) task
    Running "concat:globalJsMin" (concat) task
    Running "concat:globalJs" (concat) task
    Running "uglify:globalApps" (uglify) task
    Running "uglify:globalJs" (uglify) task 

I am running grunt 0.4.5 on Mac OSX 10.10.2. Could you have a look and let me know if there is a solution to this?

Kind regards,
Alex.

Use Gruntfile from a sub directory

Hi guys,

I use a shell wrapper who run the gruntfile from a sub directory and I receive this message:

Fatal error: Unable to find local grunt.

If you're seeing this message, either a Gruntfile wasn't found or grunt
hasn't been installed locally to your project. For more information about
installing and configuring grunt, please see the Getting Started guide:

http://gruntjs.com/getting-started
    Warning:  Use --force to continue.

    Aborted due to warnings.

The hole structure is:

root
└── wrapper.sh
└── config_folder
  ├── gruntfile.js
  ├── package.json
  └── node_modules
└── target_folder
  ├── css
  ├── sass
  ├── js
  └──img

I also have in my gruntfile grunt.file.setBase('../');
Everything works OK except the concurrent tasks who are:

concurrent: {
      dev: {
        options: {
          logConcurrentOutput: true
        },
        tasks: ['watch:styles_dev', 'watch:scripts_dev']
      },
      dist: {
        options: {
          logConcurrentOutput: true
        },
        tasks: ['watch:styles_dist', 'watch:scripts_dist']
      }
    }

Partial logConcurrentOutput

At the moment there just a switch for logging: either log all at the end or non-deterministically intersect the logs. How about being able to specify one file for continuous logging and rest for bulk logging. This way you get continuous feedback while also keeping a good history of the log.

A scenario for this would be: User has 2 tasks which each run for 5 minutes and both have massive output. We want continuous feedback from task1 to figure out the ETA and then bulk the output of the other task at the very end.

I am happy to try open a pull request if any of the choices are part of the philosophy of the library.

Prefix logged output with task name.

It would be very useful if the logged output was prefixed with the task name, possibly even in some kind of color. That way it's much easier to understand which task is producing which output. I haven't looked at the codebase, but I could give a shot at implementing this feature via forking and pull-request if you like.

Propagate Exit Status of Child Processes

i run functional test suites in multiple processes using grunt-concurrent. it seems that grunt-concurrent does not propagate the exit status of any child processes up to the main process when finishing its work.
is there an easy way how i can achieve this or would this be a desirable feature for a future release?

thanks,
manu

stdout isn't padded when logConcurrentOutput is true

module.exports = function (grunt) {
    grunt.loadNpmTasks('grunt-concurrent');
    grunt.registerTask('log', 'Log to the console.', function (message) {
        console.log(message);
    });
    grunt.initConfig({
        concurrent: {
            logNo: {
                options: {
                    logConcurrentOutput: false
                },
                tasks: ['log:one', 'log:two']
            },
            logYes: {
                options: {
                    logConcurrentOutput: true
                },
                tasks: ['log:one', 'log:two']
            }
        }
    });
};
$: grunt concurrent:logNo
Running "concurrent:logNo" (concurrent) task

    Running "log:one" (log) task
    one

    Done, without errors.

    Running "log:two" (log) task
    two

    Done, without errors.

Done, without errors.
$: grunt concurrent:logYes
Running "concurrent:logYes" (concurrent) task
Running "log:two" (log) task
Running "log:one" (log) task
one
two


Done, without errors.
Done, without errors.





Done, without errors.

2.0 does not seem compatible with bunyan logger

Node: v0.10.38

I'm finding that updating from grunt-concurrent 1.0.1 to 2.0.0 breaks the bunyan (v1.4.0) json output formatting in my console.

Output using grunt-concurrent (v1.0.1) with bunyan (v1.4.0):
screen shot 2015-07-06 at 11 49 57 am

Output using grunt-concurrent(v2.0.0) with bunyan (v1.4.0):
screen shot 2015-07-06 at 11 53 17 am

I can't seem to pinpoint the change that could cause this. I'm passing the process.stdout object to bunyan like so:

var CONFIG = require('config');
var bunyan = require('bunyan');

module.exports = function (name) {
    return bunyan.createLogger({
      name: name || 'myproject.js',
      stream: process.stdout,
      level: CONFIG.app.logLevel
    });
};

Is there anything in the new grunt-concurrent version that may alter the way stdout is being passed?

Improvement: logConcurrentOutput to consider progress

We had a problem tracking down a hang which happened in htmlmin of a combined concurrent task of svgmin, imagemin, htmlmin and unfortunately even with logConcurrentOutput set to true it didn't reveal the hanging htmlmin.

It seems that it gives output once the output is there from a task, but it does not show progress? Would it be possible to change this logic to incl. progress as well? That would give feedback on a hanging process (in the above case, a file).

grunt-concurrent should not assume Gruntfile.js is current directory

I'm aware of this issue that was closed:
#21
However, I'm not using a shell-script wrapper so that solution does not work for me.

I want to run with Gruntfile.js in a subdirectory. I really must be able to set my distribution folder above the folder containing Gruntfile.js which means I need to be able to delete files in a directory above Gruntfile.js yet I don't want to set force:true which gives grunt control over all directories on my machine when I mis-type a directory path.

The structure I want is like this:

root
└── websrc
├─ Gruntfile.js
├─ package.json
└─ node_modules
└── web
├─ bower_components
├─ css
├─ sass
├─ scripts
└─images
└── webdist
├─ bower_components
├─ css
├─ scripts
└─images

I want to execute grunt in the websrc subdirectory yet I want it to be able to cleanup files in the ../webdist directory at the beginning of its run. The other tasks work when the path is specified but grunt-concurrent unlike other grunt tasks assumes that the grunt.setBase() directory is where the Gruntfile.js is at which is not true in my case. Grunt-concurrent throws this error:

Running "concurrent:test" (concurrent) task
    Warning: grunt-cli: The grunt command line interface. (v0.1.9)

    Fatal error: Unable to find local grunt.

Making grunt-concurrent work with setBase('.../')

Would it be possible to have an option on grunt-concurrent to set the location that grunt-concurrent should find the Gruntfile.js ? That way grunt-concurrent work work with setBase like the other grunt commands that work with setBase?

Separation of Grunt from Other Code needs setBase('../'') or safe delete

I'm trying to find a way to keep grunt code separate from server-code. Both Grunt frameworks and the server frameworks assume that they are in the directory immediately above the web directory which makes for a confusing merger of files and directories at that level. I'd like to have a separation of concerns. It makes updates and commits confusing too when both frameworks have to share the parent directory to the web directory.

It is really messy to merge the main directory of a Yii PHP application with a Yeoman-Grunt front-end because they both assume they are the direct parent of the web directory. It becomes dozens of directories without clear ownership. I'd like to separate them out so that Grunt stuff goes in one directory and Yii PHP stuff in another. The best organization would be for Grunt to have its own subdirectory that could modify a peer directory.

setBase('../) as workaround for no safe deleteDirs config option

So I tried setting up grunt and Yeoman this way. It almost works except that the grunt script cannot delete files in a peer directory to the directory the Gruntfile.js is in. So I found the technique of using the setBase after the require and config but before the register tasks like this article describes:
http://stackoverflow.com/questions/18195095/put-grunt-in-a-subdirectory

// now that we've loaded the package.json and the node_modules we set the base path
// for the actual execution of the tasks and before the registerTask
  grunt.file.setBase('../');

That works except that grunt-concurrent breaks with the error: Fatal error: Unable to find local grunt.

Need Configurable Safe Delete outside current Gruntfile.js folder

I don't want to use the force:true command or option because if I mis-type something then I will blow away a large chunk of files on my machine. I just cannot take the risk of having force:true. It is a shame because I know exactly which directory I want to allow writes on yet there is no way to add additional directories to the rules throughout the grunt plugins that prohibit deleting files outside the directory the Gruntfile.js is in. I'm tempted to branch and custom code the plugin myself but could take quite awhile. The force:true option does not give me the ability to specify additional trusted directories that I'm allowed to delete files in. This would be a way of defining safe delete. I wish there were a forceDirs: ['../webdist'] option that would loosen the grunt rule that doesn't allow deleting outside the current directory.

Firing a callback when grunt-concurrent is quit with CTRL-C?

I've struggled today to figure out if there's any way to force the firing of a callback when grunt-concurrent gets quit from the command line with a CTRL-C. Is there?

In my specific case, I'm using it to run nodemon and watch, so those are the two concurrent threads. I'm specifically trying to fire a callback after nodemon quits (so that I can clean up a few files); I've tried to add a nodemon listener (for either/both of nodemon's 'exit' and 'crash' events), to no avail; it looks like concurrent kills nodemon before those listeners can fire off the callbacks. I've also played with various process.on() calls, but those callbacks get fired for all three running processes (the master grunt process and the nodemon and watch process), so it's messy having them figure out which is the right one to do the work.

Thoughts?

Concurrent tasks losing the grunt.config context

It seems like tasks started via concurrent don't have access to the parent config vars.

grunt.registerTask('server', function () {
    grunt.config.set('HOST', 'lvh.me:3000');
    grunt.task.run([
      'concurrent:xyz'
    ]);
  });

The task xyz will not have access to the HOST variable. If the task is run without concurrent, it works fine. Maybe this is by design, I'm not sure, but it's sure unexpected.

Dependency pad-stdio oddly unavailable?

I see that grunt-concurrent has 'pad-stdio': '^0.1.0' set as a dependency, but running npm install in a project that has grunt-concurrent throws the following error that I've been trying to debug all night but to no avail:

Error: No compatible version found: pad-stdio@'^0.1.0'
Valid install targets:
["0.1.0","0.1.1"]

Any ideas...?

Grunt task with concurrent and watch

I am trying to watch two directories concurrently and apply changes to each specific directory independently whenever that directory changes. The problem I encounter is when I launch the task, the console says it's watching but when I change a file, it doesn't trigger the watch tasks even if I specified the two watch tasks in the concurrent target.

module.exports = function(grunt){
  require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks);
  require('time-grunt')(grunt);

  grunt.initConfig({
    coffee:{
      models:{
        files:[{
      expand:true,
      cwd:'src/models/',
      src:['*.coffee'],
      dest:'dev/models/',
      ext:'.js'
    }]
      },
      tests:{
         files:[{
       expand:true,
       cwd:'src/tests/',
       src:['*.coffee'],
       dest:'dev/tests/',
       ext:'.js'
     }]
      }
    },
    coffeelint:{
      models:{
        files:{
      src:['src/models/*.coffee']
    }
      },
      tests:{
        files:{
      src:['src/tests/*.coffee']
    }
      }
    },
    watch:{
      models:{
        files:'src/models/*.coffee',
    tasks:['coffeelint:models', 'coffee:models']
      },
      tests:{
        files:'src/tests/*.coffee',
    tasks:['coffeelint:tests', 'coffee:tests']
      }
    },
    concurrent:{
      compile:['watch:models', 'watch:tests']
    }
  });

  grunt.registerTask('compile', ['concurrent:compile']);

};

Concurrent task running into directory already created.

Not sure if this is a concurrent task issue:

Running "concurrent:dist" (concurrent) task
Reading target file...
New Shard Created.
Warning: Running "htmlmin:dist" (htmlmin) task
Warning: Unable to create directory "/website/dist" (Error code: EEXIST). Use --force to continue.

Aborted due to warnings. Use --force to continue.

We have grunt building in maven, sometimes it's htmlmin sometimes it's imagemin that runs into this error.

Task doesn't get executed

I've got two blocking tasks namely gapreload-serve and watch which I setup as the following ( gapreload-add is non-blocking):

concurrent: {
  options: {
    logConcurrentOutput: true
  },
  gapreload: ['gapreload-add', 'gapreload-serve'],
  watch: ['watch']
}

Which is used inside a custom task as:

grunt.registerTask('idev', ['build:development', 'concurrent:gapreload', 'concurrent:watch']);

Now while running grunt idev after concurrent:gapreload is successfully run I don't see any output for the concurrent:watch execution as it does not get invoked at all. Following the relevant console output:

...
...
...
Running "concurrent:gapreload" (concurrent) task
Running "gapreload-add" task
Running "gapreload-serve" task
Running "exec:gapreload-serve" (exec) task
Running "exec:gapreload-add" (exec) task
Fetching plugin "pro.fing.cordova.gapreload" via plugin registry
Static file server running on port 8000 (i.e. http://localhost:8000)
CTRL + C to shut down
Plugin "pro.fing.cordova.gapreload" already installed on ios.

Done, without errors.

--stack argument

I have a concurrent task:

grunt.registerTask('dev', ['concurrent:dev']);

this is configured as follows:

    concurrent: {
        dev: {
            tasks: ['watch:dev', 'dev-trigger'],
            options: {
                logConcurrentOutput: true
            }
        }
    }

I run it with:

grunt dev --stack

No stack traces

If I do

grunt watch:dev

I get the stack traces correctly.

My take: grunt-concurrent is not appropriately passing the --stack option to the subtasks, where in my opinion, it definitely should.

Error handelling Multiple flag

I'm using grunt-concurrent v0.5.0

At the end of my Gruntfile I call the following function

traceContext();
function traceContext(){
        grunt.log.subhead('Options' );
        grunt.log.writeflags( grunt.option.flags() );

        grunt.log.subhead('Context' );
        grunt.log.writeflags( grunt.config.get('context') );
    }

I run the following command line
`grunt build:dist --env=development --local=true``

Before each concurrent task traceContext is called and output

    Options
    Flags: --target=dist, --local, --env=development

    Context
    Flags: public="dist-development", source="app", target="dist", env="development"

While concurrent run before each task

    Options
    Flags: --target=dist, --local=--env=development, --env=undefined

    Context
    Flags: public="dist", source="app"

Notice here --local=--env=development.

Concurrent output logs not colorized

When using logConcurrentOutput = true, the text for the logs are not colorized. This seems to be a result of the change to piping to stdout as changing the code back to the former way fixes the issue.

Reproduction steps:

  1. Create node project utilizing npm install debug and create some debug output
  2. Run project via grunt-concurrent and grunt-nodemon with env variable DEBUG=*
  3. Observe output to stdout

I've seen this behavior through putty and mobaXterm running on Windows while using SSH to connect to a linux machine running Red Hat Enterprise 6.2. I have not tested this on other systems.

"[object Object]" in args

Using concurrent with this config:

grunt.config('concurrent', {
    server: [
      'modernizr',
      'copy:styles'
    ]
  });

Ends up:

Running "concurrent:server" (concurrent) task
    [ 'modernizr',
      '--force',
      '--_modernizr.defaults=[object Object]',
      '--_modernizr.private=[object Object]' ]
        [ 'copy:styles',
      '--force',
      '--_modernizr.defaults=[object Object]',
      '--_modernizr.private=[object Object]' ]

If I log args in the task

var cp = grunt.util.spawn({
                grunt: true,
                args: args2,
                opts: spawnOptions
            }, function (err, result, code) {
                if (err || code > 0) {
                    grunt.warn(result.stderr || result.stdout);
                }
                grunt.log.writeln('\n' + result.stdout);
                next();
            });

grunt-modernizr ref https://github.com/Modernizr/grunt-modernizr/blob/master/tasks/modernizr.js#L15

Should stderr be visible by default?

I was running a task and see

Running "concurrent:test" (concurrent) task

    Running "coffee:dist" (coffee) task
    >> 2 files created.
    >> 2 source map files created.

    Running "coffee:test" (coffee) task
    >> 1 files created.
    >> 1 source map files created.

    Done, without errors.


    Execution Time (2015-05-04 01:58:55 UTC)
    loading tasks   8ms  ▇▇▇▇ 7%
    coffee:dist    85ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 78%
    coffee:test    16ms  ▇▇▇▇▇▇▇ 15%
    Total 109ms
        Warning:  Use --force to continue.

        Aborted due to warnings.


Execution Time (2015-05-04 01:58:51 UTC)
concurrent:test  5.9s  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 100%
Total 5.9s

It took me a while to figure out what was wrong with my code.

If I set logConcurrentOutput to true I see

Running "concurrent:test" (concurrent) task
Running "coffee:dist" (coffee) task
Running "compass:dist" (compass) task
>> 2 files created.
>> 2 source map files created.

Running "coffee:test" (coffee) task
>> 1 files created.
>> 1 source map files created.

Done, without errors.


Execution Time (2015-05-04 02:02:48 UTC)
loading tasks   7ms  ▇▇▇▇ 6%
coffee:dist    94ms  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 81%
coffee:test    14ms  ▇▇▇▇▇▇▇ 12%
Total 116ms



    directory .tmp/styles
    error app/styles/main.scss (Line 132: Undefined variable: "$header-height".)
Compilation failed in 1 files.
Warning: ↑ Use --force to continue.

Aborted due to warnings.


Execution Time (2015-05-04 02:02:48 UTC)
compass:dist  1.4s  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 100%
Total 1.4s

    Warning:  Use --force to continue.

        Aborted due to warnings.


Execution Time (2015-05-04 02:02:44 UTC)
concurrent:test  5.5s  ▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇▇ 100%
Total 5.5s

Although the report is a bit messy (#43) I can see the error message.

I was hoping to see errors by default unless its turned off purposely.

Command line argument --gruntfile

tl;dr - This plugin doesn't respect --gruntfile grunt-cli argument (flag).

I am using this task as a part of Yeoman. My requirements are to use another Gruntfile.js, I'm calling altGruntfile.js here.

This command grunt build --gruntfile altGruntfile.js fails when I remove the standard Gruntfile.js when it gets to: Running "concurrent:dist" (concurrent) task

Running "concurrent:dist" (concurrent) task
----------------------------------------------------------------
    Warning: A valid Gruntfile could not be found. Please see the getting started guide for
    more information on how to configure grunt: http://gruntjs.com/getting-started
    Fatal error: Unable to find Gruntfile. Use --force to continue.

        Aborted due to warnings.

When the standard Gruntfile.js remains, the concurrent:dist seems to use the settings it rather than using the settings from altGruntfile.js even when running the command:

grunt build --gruntfile altGruntfile.js


BTW, when I remove concurrent:dist from build task, and replace with tasks that should be run concurrently, it works as expected.

grunt-concurrent hides errors

Just spent a couple hours trying to decode a cryptic error message on a yeoman-derrived project. As soon as I moved the task to run outside concurrent, I got the full description of the error. For the record, the issue was with grunt-contrib-coffee and in particular, an error in a coffeescript file that was to be compiled.

Output isn't padded on Windows

Tested on Windows 7 x64, Node v0.10.31 and Windows 8.1 x64, Node v0.12.2 using example in #43. Here's the output I get:

>grunt concurrent:logNo
Running "concurrent:logNo" (concurrent) task

Running "log:two" (log) task
two

Done, without errors.

Running "log:one" (log) task
one

Done, without errors.

Done, without errors.
>grunt concurrent:logYes
Running "concurrent:logYes" (concurrent) task
Running "log:one" (log) task
one

Done, without errors.


Running "log:two" (log) task
two

Done, without errors.



Done, without errors.

Watch task with Livereload

I've been playing around with this for a bit, and using grunt-concurrent with the 'watch' task listed inside it seems to break livereload.

Forgive me if I misunderstand, but if grunt-concurrent spawns a new grunt task for each one in its list, it seems when 'watch' triggers a 'livereload' task, the livereload task is run on a separate grunt from the 'livereload-start' task, and thus doesn't have a handle to the livereload server. I think that's why I get the error message:

> Server is not started. Please do call livereload-start prior to any other task.

I get this even though I start the 'livereload-start' task before the concurrent task. Does this theory sound right?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.