-
-
Notifications
You must be signed in to change notification settings - Fork 30
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
Fixes made by blueimp #47
base: master
Are you sure you want to change the base?
Conversation
We need the delay here because the TAP reporter calls mochas runner end event and writes final lines there and at the same time we use the same runner end event to emit our 'ended' event which starts closing the browser. This means that the browser usually closes before the TAP reporter has written all of its last lines
window._eventbus.emit('ended', m.runner.stats); | ||
setTimeout(()=>{ | ||
window._eventbus.emit('ended', m.runner.stats); | ||
}, 2000) |
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.
arbitrary timeouts are never a predictable or portable thing. two seconds is also a very long time. perhaps you're looking for a deferred promise?
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.
Sorry, I didn't realise that we made the PR from our forks master branch. The timeout was meant as a temp solution for our system where chrome gets shutdown before the reporter finishes.
It would make sense to close this PR and use the other open one as it contains the same fixes: #45
@@ -1,6 +1,6 @@ | |||
{ | |||
"name": "mocha-chrome", | |||
"version": "2.2.0", | |||
"name": "digabi-mocha-chrome", |
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.
I cant accept this change. I wouldn't recommend having your team commit to a fork branch that has an open PR
I'm not sure what's going on here with the multiple contributors on the PR branch, but there's a lot not done correctly. The changes to the flags are breaking changes, which means a new major version. And that's not something that needs to happen. The user-facing flags don't need to change, and they can be passed to the internal mocha object with the correct name, without breaking for users. |
This PR contains:
Breaking Changes?
If yes, please describe the breakage.
Please Describe Your Changes
colors
tocolor