readability of JSHint output about grunt-contrib-jshint HOT 7 CLOSED

I really like the idea! I've been having issues with the readability myself, would be awesome if you'd build this.

from grunt-contrib-jshint.

That output looks like an improvement to me. Would be useful as a separate module so other libs can also use it too. Thanks!

from grunt-contrib-jshint.

Looks good.. can I suggest prepending the line with a ERROR or WARNING though?

Until this task can emit something that's friendly to Jenkins, regex matches are the only way to capture these inside of the build server right now.

If #13 gets pulled at any point, that can be used... but it looks like its a ways off.

from grunt-contrib-jshint.

Great feedback @yoshuawuyts, @shama, @Iristyle.

It sounds like we want improved human readability, but also want machine-readability for tools like Jenkins. Because these two goals are typically incompatible perhaps a more flexible solution is desired.

We could create two output methods and an option to pick which one to use.

Another option is to have a reporter feature simular to Mocha. This would increase the amount of work for this feature considerably (I'm guessing mostly in design of the feature) but it means it could be reusable by other tasks and possibly user-customizable with their own templates.

@cowboy, opinions on this?

from grunt-contrib-jshint.

Yeah, a reporter seems to more or less be the standard approach in a number of tools, like Mocha and Testacular (now Karma).

If I could push out xml that's directly consumable by Jenkins w/out any regex parsing that would be ideal.

See more on this here:
gruntjs/grunt#520

from grunt-contrib-jshint.

[L1:C1] W097: Use the function form of "use strict".

Did it fixe? I think it must be fixed. Because Angularjs often will add this commont.

from grunt-contrib-jshint.

awesome

from grunt-contrib-jshint.