move less important reporters in to npm-land

[tj]

I think we should move CI-specific reporters into npm-land, "teamcity", "xunit" can simply be "teamcity-reporter" etc in npm and add to https://github.com/visionmedia/mocha/wiki#interfaces--reporters

[ForbesLindesay]

👍

[jonathanong]

which ones should we include?

[tj]

I guess depends on their usage, not that I have much of say anymore :D but I'd keep dot/spec/nyan I use those ones lots, the rest are meh but many are simple enough that it's not a burden keeping them in here. Moving them all out just gives you the classic node over-modularization dwindle until useless feel

[jonathanong]

if anything, we could just move most/all of the reporters to a separate repo and just use it as a dependency. that way, we can separate the presentation vs. logic and the people who like pretty reports could have a field day. a lot of these issues are for reporters and i don't want to touch them

[jbnicolai]

I would keep the core ones in, as @visionmedia suggests. Dot, Spec and Nyan sounds good - although the latter already seems to me like it could be moved out as well.

[travisjeffery]

people can already make and use their own 3rd party reporters. so what's the point of moving them all out into a separate repo? all the reporter issues will pile up there. if some are moved out, i'd rather try having them be in separate repos. e.g. an xunit-reporter repo. and perhaps then find people who use each integration and make them a collaborator since they use/care about them. xunit is big enough of a burden that it should be moved out though. other than that i'm not so sure.

[jbnicolai]

Definitely. If we move them out, it's a repo per reporter. I thought that's what we were discussing in the first place ;)

[jonathanong]

haha i was thinking about just moving htem to a separate repo because i'm lazy, but a repo per reporter is cool. maybe split them up into a mocha-reporters org?

[jbnicolai]

👍 a mocha-reporters org with the same maintainers as visionmedia/mocha sounds like a plan

[jbnicolai]

Then the main question is: which ones? I think leaving spec, dot and nyan will suffice - but perhaps you guys would like to keep an other one mainline as well?

[jonathanong]

and the html + html cov stuff.

[jonathanong]

created the org if you guys are interested

[jbnicolai]

I've created a proof of concept for this at mocha-reporters with the TAP reporter. The approach I've taken is:

• A mocha-reporter-base package containing the base utilities from the mocha repository: base.js, utils.js and ms.js
• A first reporter, mocha-tap-reporter. NOTE: the name could not simply be tap, as this package name has already been taken. This means the reporter is called with mocha --reporter=mocha-tap-reporter rather than mocha --reporter=tap, constituting a breaking API chance.
• A branch of mocha without the tap reporter

To run this locally:

• Clone mocha-reporter-base and npm link
• Clone mocha-tap-reporter, npm link mocha-repotrer-base and npm link
• Checkout the split-reporters branch and npm link mocha-tap-reporter
• Run ./bin/mocha --reporter=mocha-tap-reporter to see it in action.

Once all the packages have been published it would merely be a matter of npm install mocha-tap-reporter --save-dev && mocha --reporter=mocha-tap-reporter of course, but I've held back from publishing until I've gathered some feedback.

@visionmedia, @jonathanong, @travisjeffery: what do you guys think? To me, the breaking api (--reporter=mocha-tap-reporter vs --reporter=tap) is a large downside, but I think acceptable if we document it clearly and have a new major release. The advantage will be that we can now move all reporters to their own, small and more 'nodesey' packages.

If we decide to do this we would have to:

• move all reporters
• test extensively
• update the documentation
• draft release notes
• make a new major release
• eat some wine gums

Thoughts? 😄

[jonathanong]

my only concern is #1260, which i think right now is being messed up by all the included reporters, so removing them would make things easier.

[tj]

why would it include all the reporters anyway? can't we blacklist?

for the ones that don't seem volatile I'd really just leave them in because what's the point ultimately, but if they're really troublesome and make sense to have their own issue tracking etc then maybe. Otherwise it's like hey cool you can run some tests, just assemble these 10 modules first

[travisjeffery]

ya i agree @visionmedia.

[jonathanong]

browserify just includes all the ones that get require()ed. i can mess with the require() calls or create a separate entry point. haven't looked into it much yet.

we could also just move some reporters to their own separate repos but include them here so we don't break backwards compatibility or make people install a billion things just to get tests running. at least this way, issues will pile up there instead of here since there are way too many issues here. we can also more liberally add more collabs to those repos

[tj]

that would be fine, I still dont think it benefits anything really but no complaints either. As far a the browserify thing goes yeah that sucks :( maybe we'd have to stub out empty modules and use its browser field or something

[jbnicolai]

I still dont think it benefits anything really but no complaints either

Note that you're the one who created the issue in the first place 😉

I guess I'll move forward with this though, as I do see an advantage in having separate repos with their own issue trackers for the reporters. There's also been some questions from users if we could move this way, e.g. #1263 from just four days ago.

[travisjeffery]

ya but the issue was originally scoped much smaller than moving them all out. just the 2 biggest pains, teamcity and xunit. teamcity is out already, so xunit should be next. then see how that goes and take it from there.

[jbnicolai]

Fair enough, I'll simply move xunit out and see how it goes. 👍

[ngeor]

Seems like xunit format is the least common denominator, supported in various build servers (jenkins, Bamboo, TeamCity). I wouldn't take xunit reporter out because it will give the impression mocha doesn't have built-in support for CI, which is not the case.

I would suggest closing this ticket as "won't fix" and say that any new reporters would have to go to their own repo (unless the community thinks they're core).