As far as I can tell, reporter isn't defined via jshint options in node.js (wouldn't really make sense).
Input to a custom report would be similar to input to jshint reporters except like this:
[
{
id: [string, usually '(error)'],
code: [string, error/warning code],
reason: [string, error/warning message],
evidence: [string, a piece of code that generated this error]
line: [number]
character: [number]
scope: [string, message scope;
usually '(main)' unless the code was eval'ed]
[+ a few other legacy fields that you don't need to worry about.]
},
//...
]
The array structure differ since all errors/warnings/info are associated to only one file, for every file the js-loader processes. Thus, traditional jshint reporters aren't compatible.
If there is no custom defined reporter, the default one will be provided.
Custom reporters are executed with the loader's context as this. This provides emit functions.
Wondering about this after looking at
As far as I can tell,
reporter
isn't defined via jshint options in node.js (wouldn't really make sense).Input to a custom report would be similar to input to jshint reporters except like this:
The array structure differ since all errors/warnings/info are associated to only one file, for every file the js-loader processes. Thus, traditional jshint reporters aren't compatible.
this
. This provides emit functions.Would this be a good idea? Let me know otherwise.
At the moment, I'm using this in my project.