-
Notifications
You must be signed in to change notification settings - Fork 779
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
Events: Use EventEmitter model for logging system #882
Conversation
335c878
to
47b7b74
Compare
I still need to figure out a way to run both logs and events tests on node. |
I never involved myself too much on the js-reporters or the Event Emitter before. Now that I'm trying to finish this pull request I have some thoughts and concerns: From js-reporters perspective, we have one non-compliant event: the js-reporters is a good project but in my own PoV, it's a great test report adapter to connect many test frameworks to many other test tools, like Karma, Grunt, Browserstack, etc. On the other side, I wouldn't like to use it for actual reporters (like html, console, tap, etc). This PR does not adapt QUnit with the event details for js-reporters, and they are not consistent yet: qunitjs/js-reporters#30. It looks like js-reporters does not support ES3 and even PhantomJS (using Function.prototype.bind without a fallback). QUnit still supports ES3 environments. We can't just ship it along with QUnit 1.x without breaking anything else. For an actual reporter and adapter, we could also solve it easily if we have an tap output. Everything else could parse a tap log, as every test framework should do it just fine as well. Maybe if we have a method to call on a With that said, my suggestion is to land this PR as it is and work on tap reporter on the top of it (without using js-reporters). The events details should be addressed only after qunitjs/js-reporters#30 is done. |
360cd50
to
a1f766a
Compare
a1f766a solves the problem with running both |
throw new Error( "Emitting QUnit events requires an event type" ); | ||
} | ||
|
||
callbacks = listeners[ type ]; |
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.
May wanna call .slice()
here at the end to ensure a consistent event run.
f8e28ea
to
1c65763
Compare
@leobalter I appreciate that you spent some time looking into js-reporters! This looks like a great opportunity to improve the js-reporters spec, instead of partially ignoring it. Since there a quite a few details to discuss, could we do a Skype/Hangouts call sometime this week? Hopefully @fcarstens can join as well. |
I'm in! |
Can we separate the addition of EventEmitter from the test-on-node refactoring? Either land that first, or keep it out for now. I'd like to review and land this pull request this month. Also, I'd like to land it without changing existing code or tests that use events. Only add a few tests for the EventEmitter. In a later patch, when we deprecate and introduce warnings for the old code, we can update the existing tests. That way I can have greater confidence in it not breaking any existing code and keeps the patch more minimal. |
Sure. I still need to work on the event details for this PR as well. |
Every test runs without the noise of other tests, this allows to run multiple loggins tests, like events and logs.
1c65763
to
f421ec3
Compare
This is rebased and the test-on-node refactoring got its own PR (more rebases on the way). I still need to finish the work on the events, which will consume some time but it's better to have new events with legacy details. |
"moduleStart", "moduleDone" ]; | ||
var dictionary = { |
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 think this should reference https://github.com/js-reporters/js-reporters#event-names
Since #981 was closed, bringing this up here again: Since it looks like the new event emitter API won't make it into 2.0.0, can we release the new API somewhere in a 2.x release, while keeping the existing callbacks intact? We could then remove the old callbacks in 3.0. New events with old event data (or both old + new data) seems like a bad idea, so I think it would be better to add the new API with new data, then eventually remove the old API.... |
Hey, I would like to continue this and to integrate the js-reporters standard into QUnit. How should I start? Should I rebase this onto master ? Thanks. |
@trentmwillis since you're working on the conversion to ES6 modules, rebasing this now probably makes no sense, right? Any idea how long you'll be working on that? |
@jzaefferer I'm hoping to have a PR ready within the next couple of days (mainly restructuring/organizing things right now). I don't necessarily think it'd be a bad idea to rebase this as the ES6 modules changes will be minimally invasive into the actual logic (mainly just adding import/export statements). |
Gotcha, thanks. @flore77 Let's try an initial rebase soon. If its non-trivial to resolve, we can still discuss when and how to make it work. |
Closing this in favor of #1026. |
Closes #422
Replaces #644
This is a rebased branch from @JamesMGreene's work on #644 to finish the EventEmitter.
[WIP]