Warn on stylus errors

[hurrymaplelad]

Fixes #51. Alternative to #52 & #70 requested by @shama.

Log out stylus errors without exiting, and without an error code. Not sure I like this. I'm using grunt-contrib-stylus as part of the build script on a continuous deployment server. It's a little scary that a deploy could go succeed when styles failed to build...

@shama @cowboy, are there other strategies for failing the build on stylus errors? Parse the grunt output and look for errors?

[shama]

Ping @cowboy @tkellen, this gets requested both ways often and I unfortunately agree with the arguments made on either side.

Aborting on error would require a force option implemented per task but not aborting on error would also require some sort of mechanism to know whether a task has erred. As much as I don't want to see more options added to tasks, adding a force option and aborting on errors seems like the path of least resistance here. Unless I'm missing a better option?

[hurrymaplelad]

We could add (or plugin) a flag to grunt monkey patching grunt.fail.* to not, process.exit but still exit with an error code if all tasks complete and any has grunt.failed. Similar to watch's forever but with support for error codes and separate so devs can run it before watch has started.

Then we don't have to add a new flag to each task individually. Thoughts?

[shama]

FWIW, you can use --force or grunt.option('force', true) now to not abort when a task warns. The force option per task is just for those who request that only some tasks should continue and some should abort. The forever option in the watch task isn't a good solution, it's terribly hacky and Im looking forward to removing it as soon as I can.

[sindresorhus]

👎 it should fail. it should be up to the user to somehow override it, but failing is the only sane default.

this is to make it work in watch right? can't we somehow fix watch instead?

[sapegin]

Why not just use grunt watch --debug? I always use it.

[shama]

@sindresorhus To me, this is just about agreeing and normalizing all contrib plugins to either abort on errors or just warn on errors.

I don't know what errors are causing the watch to fail, for me it works with both spawn/nospawn: https://gist.github.com/shama/8270974

[hurrymaplelad]

I've run into problems with tasks that do more than watch: build everything, start a server, then watch. If anything fails before the watch starts, I have to kick it off again.

[shama]

@hurrymaplelad Wait, before the watch starts or before the watch starts again? Starts again = watch task was already running, files triggered a task run and started the watch task again. If it is before the watch starts, then it has nothing to do with the watch task.

[hurrymaplelad]

@shama Before the watch starts. Agreed, nothing to do with the watch task directly, but the only times I've wanted to continue on error are when watch will eventually start, so when I fix the logged error I see the built styles without running another grunt task.

[shama]

@hurrymaplelad Does grunt --force, grunt watch --debug or grunt.option('force', true); in your gruntfile work for your use case?

[hurrymaplelad]

@shama:

grunt --force and grunt.option('force', true) both work for my case, although they still exit with code 0. Not an immediate problem but it makes me a little uncomfortable.

grunt --debug doesn't do it for me. A stylus error in the initial build exits grunt.

[hurrymaplelad]

I'd be fine closing both my pull requests, keep failing on errors. I'll use --force and open a new issue if the unsettling exit code causes problems.

[vladikoff]

Related gruntjs/grunt-contrib-csslint#21 ❕

[simshanith]

@hurrymaplelad While this may not be the right forum, you could break out your tasks with grunt-concurrent from @sindresorhus to kickoff the initial build, server and watchers simultaneously. Because the watcher(s) is/are running in a separate process, the initial build failure won't kill the watchers and subsequent changes can trigger (hopefully successful) builds.

[vladikoff]

gruntjs/grunt#1163