- Intern
- QUnit team does not have a good relationship with Colin. Can we fix that? Otherwise any collaboration on Intern is pretty much impossible.
- If we can get out of the way, we could look at the technical issues.
- node-qunit
- What are we going to do with it? Keep standalone as CLI client? Or integrate into qunitjs directly?
- Should at least merge version range for qunitjs package and make a new release, along with fixing whatever else breaks when updating from 1.10 to 1.20: https://github.com/kof/node-qunit/pull/118
- event-emitter
- Does it make sense to adopt js-reporters in QUnit if no one else adopts it? Yes, since its a good interface.
- Update QUnit EventEmitter PR with the proper details and remove old details from the new events, keep them only on old events.
- js-reporter compatible implementation blocker for QUnit 2.0/
- TAP
- Can we create a TAP adapter to use existing TAP reporters, to produce js-reporter output?
- Is TAP as or more comprehensive than js-reporters? If so, we don’t really need js-reporters and should just use TAP. If not, we can still generate TAP from js-reporters.
- We could add a tap property to the runEnd event, to support TAP output along with the regular interface. Orthogonal to everything else discussed here.
- js-reporters
- Reviewed https://github.com/js-reporters/js-reporters/issues/30 to add missing data types and missing details for errors. Leo to create pull request to add those to the spec.
- warnings
- link to 2.x migration guide, need to extend that for the event emitter
- QUnit 1.x should do single warnings for all uses of deprecated methods
- QUnit 2.0 helpfully breaks
- QUnit 2.1 unhelpfully breaks