new html-formatter: in process apis? #316

mikehaas763 opened this Issue Dec 10, 2017 · 6 comments


None yet
2 participants

mikehaas763 commented Dec 10, 2017

I'm trying to get the hang of the new way to build formatters. Will the new html-formatter only have a stdin and tcp socket api? Will I ever be able to invoke it directly from a custom formatter without reaching into "private" pieces of

If not, is the plan that going forward custom formatters will be built on this stdin contract?


aslakhellesoy commented Dec 10, 2017

Hi @mikehaas763

The HTML formatter you're pointing to is, as I'm sure you've figured out, a crude proof of concept.

I think it makes sense for it to have a STDIN API so it can be launched from a Cucumber implementation, consume events, write HTML to disk and shut down.

I think it also makes sense to have a TCP API so it can be started in "server" mode, and just listen for incoming events.

For other formatters (such as a pretty formatter) I think STDIN only makes more sense.

I think we still need to improve all of the Cucumbers (Ruby, JavaScript and Java) to be able to write events to STDOUT.

mikehaas763 commented Dec 10, 2017

@aslakhellesoy yes I realized that because there's not a whole lot of docs for it yet 🙂

I definitely don't have a problem with the stdin api, just trying to wrap my head around how it's all supposed to come together. If I understand you correctly, the idea is that in the future the different cucumber implementations will programmatically write events to stdout. Do any of the cucumber implementations (particularly cucumber-js) support writing the events to stdout today?

So then the expectation is when we run cucumber we'd always be piping? eg cucumber | formatterA | formatterB?

Assuming that the intent is for consumers to pipe events from cucumber stdout to formatters stdin--I had a random thought on my drive in to work this morning--we could write an sdk "harness" like thing that knows how to read the events coming from stdin and creates the correct EventEmitter or whatever the implementation is that downstream formatters would listen to. It would make it super simple for downstream formatter creators


aslakhellesoy commented Dec 11, 2017

We could do cucumber | formatterA | formatterB, but I think that could potentially degrade the UX/DX. It would require people to independently install those formatter executables, but them on their paths etc.

I think it would be more user friendly if they could also do like now: cucumber --format formatterA --formatterB, and it's Cucumber that will be in charge of spawning the subprocesses for formatterA and formatterB, writing events to their STDIN stream.

I think we need some feedback from users before settling on any of these.

stale bot commented Feb 9, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

@stale stale bot added the Stale label Feb 9, 2018

Makes sense, will be exciting to see this come together.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment