Diff colors, configuration, streaming...

[tapjs]

Diff colors, configuration, streaming...

[isaacs]

If you're not running a terminal with 256 color support (tmux in default config, for example), the default reporter's default diff configuration … is … impossible to read.
It would be nice if this behaved properly without requiring source diving to figure out what's going on

I agree! I did a bit of investigating on this a while back.

Turns out that tmux is rather annoying in that it reports a TERM value to programs indicating that it can do 256 colors, but then converts them all back down to 8bit. There's really no way that I know of to work around this. I recommend running tmux with -2 to enable 256 colors.

In the meantime, patch welcome to use an alternative color scheme if 256 colors is not supported.

It's additionally confusing that TAP's reporters appear to be using Mocha's API, but aren't actually respecting the values from the base reporter itself, which specifies entirely different colors.

Yes, well done, you've discovered that this is a bit of a frankenstein module. Probably the 0.0.x version number was a bit of a tip-off. I'm amazed that it's gone this long without a full rewrite, but it gets the job done, and most people seem to prefer either the default -Rclassic or -Rspec in node-tap, so it works ok.

I'm not a fan of Mocha's reporter API at all, however: given that mocha reporters output to console.log, lots of problems arise (such as log or error messages cropping up in xml reporter output). Since TAP maintains a set of streams, it would be excellent if this separation could be carried forward into the reporter API, allowing for discretely piped input into the reporters themselves and possibly multiple reporters.

This module takes TAP, and writes something prettied up for humans on stdout. Node-tap isn't "maintaining a set of streams", as you say. A new reporter API would be lovely, but I haven't had time to write one. The goal of this hodgepodge of junk was to be able to use the most popular existing Mocha reporter classes, and have something that can output spec or TAP or node-tap style results, without me having to fully learn all the intricacies of spec reporting.

I wouldn't be averse to contributing some code on this count, though I could use rather a lot of help refactoring / understanding how to hook into tap's output in order to consume it in such a manner.

This module doesn't output TAP. (Unless you use the tap reporter, which is actually just a glorified cat, except that it sets the output status if there's a failure.) It is a reporter, and its job is to dump pretty junk to stdout.

You don't need to know "how to hook into tap's output". It's a writable stream, it hooks into a tap-parser, and it consumes the events that parser issues, and writes pretty junk to stdout.

If you wanna refactor it completely and build a better one of these, that does the same thing, and works the same way this one does (ie, zero config except the reporter choice, takes TAP input, writes pretty stuff to stdout) then by all means, go nuts. There's no real "design" that went into this thing (hell, I hardly know how it works), but it has a simple job and it does it ok enough for my purposes.

I suppose it kind of breaks the TAP mentality to have the reporter tied to the output this way, but to be honest, once you've merged everything into a single output stream it can be difficult or impossible to un-merge it all again!

If you want to get at raw TAP streams, then don't use a reporter. The reporter is only for human consumption, not machine parsing.

(On the other hand, given that the streams are merged by the runner and not the "test anything protocol" itself, perhaps it is within the tap module's purview after all?)

The test runner runs each test script as a child test. Try running your tests with -Rtap to see what gets sent to the reporter.

One last thing regarding the diffs - why is null printed as [null]? This is very confusing.

Idk. Ask @tj.

In the future can you please try to stick to a single complaint/request/comment per issue? It is very hard to know how to respond otherwise.