Usability is key in any toolchain and I was not happy with the reporters some much-used tools provided. Luckily many offer a API to add custom reporters so early in my JavaScript conversion I created a bunch of reporters that work well in WebStorm.
| npm | mocha-unfunk-reporter |
| npm | unfunk-diff |
| diff | gallery |
| diff | travis |
When using WebStorm on Windows the integrated terminal doesn't handle fancy ANSI escape codes and cursor controls very well.
This was especially noticeable in mocha testing. So my first-ever npm module was a spec-style mocha reporter without console funkyness. Just plain console.log() and some optional ANSI colors.
It also has a custom string/object diff renderer. It uses existing string and object diff modules but formats the output in way that works both with-or-without color support, and can diff strings nested in objects. It looks a bit odd at first-sight but it works pretty good once you get used to it.
| npm | jshint-path-reporter |
| tslint-path-formatter | |
| eslint-path-formatter |
Because linting code is important to keep quality high I use JSHint (and ESLint and TSLint too). I found out WebStorm has a feature that parses external-tool output and uses a RegExp to make paths+locations clickable (it is used for clickable stack-traces).
So there is a triplet of report formatters that facilitate this. Of course some IDE's like WebStorm have built-in support for linters, but not all of them. And these don't work on CI like Travis or AppVeyor. My reporters work great in a gruntfile as they are not dependent on anything external.
| npm | grunt-todos |
This was an existing project used to report TODO's in code. I use it a lot but it had some bugs. The owner disappeared from the internet so I went through npm-support and got maintainer access on it so I could push fixes for the open issues.
One of the bundled reporters does the clickable path thing I mentioned above, so you can navigate through the code by clinking in your console.