-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
formatters: include html-formatter as a built-in option #1432
Conversation
I have an issue with this where the output file will end just after the script tags that sets I think we need a way for formatters to indicate they are doing some asynchronous work, so we can let them finish before cleaning up. I'll have a go at doing that in a lightweight way now. In the meantime let me know if I'm missing something (I am pretty new to streams in Node so may well be). |
return async function () { | ||
await bluebird.each(formatters, async (formatter) => { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Almost all of the rest of this file is just indentation changes - this is the addition, where we wait for each formatter to be finished.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thoughts on making the default formatter finished
function end the stream?
Then for the html formatter, it waits for the cucumber html stream to finish and then also awaits on super? Think that simplifies this a little bit.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That does seem like a good balance.
In cases where the formatter has asked to write to stdout
, we can't just end the stream when the formatter is done writing, because the process still needs stdout
. The current code accounts for this by not adding it to the list of streams to end.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If a formatter's writable stream is written to by piping another readable stream into it, then we just have to wait until the pipe is finished. We cannot prematurely close it.
This is what's happening in this case. The CucumberHtmlStream is piped to the formatter's stream. We have no control over when it's done.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay I have pushed something which I believe accounts for all of this whilst keeping a straightforward API for formatter authors - though not sure it really comes out any simpler. Let me know what you think. Also clarified my comment above.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That does seem like a good balance.
In cases where the formatter has asked to write to
stdout
, we can't just end the stream when the formatter is done writing, because the process still needsstdout
. The current code accounts for this by not adding it to the list of streams to end.
I think it would be best to wait for it to have written everything. The correct way to keep stdout open is to stream.pipe(process.stdout, {end: false})
The question is - who's responsible for closing a formatter stream? Is it the formatter itself, or is it the runner? In Cucumber-JVM it's each formatter's responsibility to close the stream, which is passed to it via its constructor. They all do this when they receive a In Cucumber-Ruby it's different. Streams are closed by the runtime before the interpreter exits. This happens in an Cucumber.js currently uses the same approach as Cucumber-Ruby. I think this is wrong. I don't think we can use Adding a timeout is not a good solution either, as it slows down execution. I think we should adopt the Cucumber-JVM model where formatters close streams themselves. This hasn't been a problem before, because all our formatters are synchronous. The HTML formatter is not, which is why this problem has surfaced now. I'm not sure how common 3rd party formatters are on cucumber.js. My proposed change would be backwards incompatible. Existing formatters that don't close their own stream would cause Cucumber to hang. I think we should try to make this change before we cut 7.x. Thoughts @davidjgoss @charlierudolph @vincent-psarga @mpkorstanje? |
I wouldn't copy the Cucumber JVM model. Rather I'd make the plugins implement a |
FWIW I changed the approach a bit here and it now works correctly. It's not that dissimilar from what you're saying in that formatters now have to declare when they are finished (rather than close the output stream themselves), but by extending the built-in
Not sure - there are a couple of popular HTML ones out there I think - at any rate 7.0.0 is already a breaking change for formatters. |
@charlierudolph @aslakhellesoy looping back to this - I know we went back and forth a bit on streams, but I'm not really sure how to improve meaningfully on what's here. It does work correctly, doesn't end streams prematurely etc, and we have got the interface for formatters to finish asynchronously in a non-breaking way. Is this okay to go in? |
Thank you for this work! When are you planning to release this, I just wanted to use this and I realized that it has been just merged. :) |
@raszi this should be in 7.0.0 in the next week or so |
* add html formatter as dependency * update run-script to use local install * add doc * add as first party formatter in switch * create our new formatter * use in formatters test * changelog, improve doc a bit * add pre script to make sure we're built * add concept of an async `finished` method on formatters * rework so it works * test html formatter roughly via formatters feature test * dont need this on the test path now * whoops missed one * what even is a computer * end stream from within formatter finished method except if stdout * update changelog again * fix botched merge
@davidjgoss - looking forward to this - when's the next release candidate? |
@nickgrealy sorry for delay, 7.0.0 was released today |
FIxes #1425