Minor fixes

[sbrandwoo]

I updated the package.json and fixed the error handling so that grunt execution would actually be stopped when something doesn't compile.

Thanks

[crudh]

I think it is better to have an option to decide if the grunt execution should be stopped when something doesn't compile, like in this commit: 2ed256c.

For a normal grunt execution you want it to stop when something doesn't compile, but if you run grunt-react from grunt-contrib-watch or grunt-este-watch you don't want the execution to stop when something doesn't compile.

[ericclemmons]

Exactly. Personally, I hate that grunt plugins have opted for throwing warnings when they fail, because people use them primarily with watch. That's what grunt-parallelize and grunt-concurrent do for you.

[sbrandwoo]

I'm not sure I follow you, as tasks causing execution to stop is exactly the behaviour I would expect when using grunt-contrib-watch or when running commands directly on the command line.

I don't think that watch is a special case here, but for myself, a typical watch could be something like this:

watch: {
    main: {
        files: ['less/**/*', 'jsx/**/*'],
        tasks: ['less', 'react', 'copy:deploy']
    }
},

If any kind of compilation fails I don't want to run the deploy commands, and I want it to be clear at the bottom of the console that something has gone wrong. Can you describe a situation where you would want to ignore a compilation failure?

My current usage is grunt build && rsync ... and I found that when compilation failed rsync would still be fired, spamming out its progress to the screen and hiding the compilation errors. We need grunt tasks to throw warnings/errors to provide us with the flexibility to build a workflow around them. If we don't know it has failed, we can't do anything.

I do think that --force is useless, as it doesn't allow any granularity of what is important and what isn't, which is why I think having force options directly on the task (such as https://github.com/gruntjs/grunt-contrib-qunit) is a better solution, as there will be unusual cases where a task doesn't affect the critical path.

Thanks

[ericclemmons]

The difference between throwing an error vs. grunt.fail.warn (which, IIRC, actually sends the "beep" to the terminal to fake an error), is the exit status:

# If grunt-react used only `grunt.fail.warn`
$ grunt react && heroku deploy
# Deployment would still take place, because grunt exit code is 0

vs.

# If grunt-react threw new Error(...)
$ grunt react && heroku deploy
# Error appears, deployment doesn't take place, as grunt exit code is 1

This is why I'd opt for 2ed256c instead of doing a BC break in 6ad5636.

Anyway, long story short, I'll sort it out so everyone wins :)

[sbrandwoo]

grunt.fail.warn will return an exit code of 1 unless the --force parameter has been given - it's one of those oddly named gruntisms :) - but it is what other contrib projects use for error reporting.

[sbrandwoo]

Moved the code and I don't believe I can update this request, so have reopened it as #25