Description
You can't really do --watch --tap, the output stream never ends, so you only get a report for the first run, then just raw TAP output:
$ ava --watch --tap | mocha-tap-reporter spec
✓ test › create must be a function
✓ test › maxSize must be number
✓ test › it will create up to maxSize handlers as needed
✓ test › a new handler will not be created if one is already returned to the stack
✓ test › pending requests will be executed as handlers are returned
✓ test › it will pass through the args
ok 7 - test › create must be a function
ok 8 - test › maxSize must be number
ok 9 - test › it will create up to maxSize handlers as needed
ok 10 - test › a new handler will not be created if one is already returned to the stack
ok 11 - test › pending requests will be executed as handlers are returned
ok 12 - test › it will pass through the args
1..6
ok 13 - test › create must be a function
ok 14 - test › maxSize must be number
ok 15 - test › it will create up to maxSize handlers as needed
ok 16 - test › a new handler will not be created if one is already returned to the stack
ok 17 - test › pending requests will be executed as handlers are returned
ok 18 - test › it will pass through the args
1..6
It's probably not possible to fix this and continue to just use the bash pipe operator to pass our output to the reporter. Since our stream never ends, I don't think the reporter will ever print it's summary, nor will it know to reset itself (I could be wrong - it seems the reporters could figure this out from the plan line, but that is likely pretty brittle).
One option would be to incorporate tap-mocha-reporter as an (optional?) dependency and allow a --tap-reporter flag. We could then handle creating separate streams for each test run, piping them to a new reporter instance each time, and correctly ending the stream.
The final option would be "Sorry, no TAP output in watch mode". Personally, I am totally fine with this option, since I prefer our own reporters. I think the real value of TAP is realized on CI servers (where you could use it to create automated reports, etc).
Also note that the tap reporter doesn't reset the test id on subsequent runs (that is a bug unless we choose the "sorry" option).