Repository navigation
EventEmitter: Inconsistent handling of once() handlers #6873
Description
Activity
- addedeventsIssues and PRs related to EventEmitter and the events module.Issues and PRs related to EventEmitter and the events module.
on May 19, 2016 It was decided in #6394 that the previous behavior was a bug, and therefor not a breaking change.
What did you have in mind as a documentation update?
#6394 has changed/corrected the behavior of signaling which listener has been removed via 'removeListener' event.
The listeners() function has not been changed in #6394, it still returns the wrapped function.I think we should either document that listeners() is not returning the registered listener or correct it to actually return the listener.
Ah, yea, @addaleax pinged @omsmith about that in #5564 (comment).
to be honest, if we could do so in a way that didn't kill perf I'd be ok with
listenersbeing modified to not return the wrapper given that the wrapper really is an internal implementation detail.- added a commit that references this issue
on May 19, 2016 Is it really proven that adding a simple unwrap in listeners() kills performance?
I would wonder that listeners() is an API which is used in performance relevant code as it creates a copy of an array. Quite a lot work - for actually getting list of functions back which has maybe "wrong" entries inside in all node versions till now.
Most use cases I have seen till now are in the end just interested in the size of the array which is available much cheaper using listenerCount() where whether copy nor unwrap is needed.
Not sure if this is the right place to ask: But as this and #6394 are seen as bugs are there also ported back to Node 4?
- added a commit that references this issue
on May 27, 2016 - added a commit that references this issue
on Jun 6, 2016 - added a commit that references this issue
on Jul 27, 2026
It seems EventEmitter has an inconsistent handling of listeners installed via once().
I think #5564 was targeting this topic also but was closed because #6394 was merged.
Not sure if this is a but or intended - or if changing this is seen as breaking change or not.
If it is kept like it is I would vote for updating documentation accordingly.