Would you accept a PR?

Use case is simple. For example, we have App which needs emitting and emit events on every method.

var util = require('util')
var Emitter = require('eventemitter3')

function App (options) {
  if (!(this instanceof App)) {
    return new App(options)
  }
  Emitter.call(this)
  this.options = options || {}
  this.cache = {}
}

util.inherits(App, Emitter)

App.prototype.set = function set (key, value) {
  this.emit('set', key, value)
  this.cache[key] = value
  return this
}

App.prototype.del = function del (key) {
  this.emit('del', key)
  if (!key) {
    this.cache = {}
    return this
  }
  delete this.cache[key]
  return this
}

App.prototype.get = function get (key) {
  this.emit('get', key)
  return this.cache[key]
}

var app = new App()
app
  .on('set', fn, {foo: 'bar'})
  .on('get', fn, {foo: 'bar'})
  .on('del', fn, {foo: 'bar'})

Feature that this package add - allow passing context to on/off/once methods, but this does not solves the problem if you want to pass same context to each listener.
Maybe this isn't the best example, but I'm using event emitter (not exactly this package, in general) to emit different type of hooks - say, before/beforeEach/after/afterEach, and I need to pass same context to them. Then when users want to listen to some hook they just add .on('beforeEach', fn), they can't add context to them - okey, they can, because if they can pass context to options, so they can pass to each listeners, but this would not be pretty and so useful and usable.

One way to do this would be to not inherit emitter directly, but write it to some property, then emit from it. But this also adds the need to create all of the listener methods (on/off/once) to allow your users to listen to that events. For example

function App (options) {
  if (!(this instanceof App)) {
    return new App(options)
  }
  this.emitter = new Emitter()
}
App.prototype.set = function set (key, value) {
  this.emitter.emit('set', key, value)
}
App.prototype.on = function (name, fn) {
  this.emitter.on(name, fn.bind(this.options.context))
  return this.emitter
}

But this leads to more unnecessary code that can be simpler if emitter can accept context through options. All this logic and stuff would be handled internally without the headaches. And this is easy to be implemented.

If this is implemented, things would look like that

var util = require('util')
var Emitter = require('eventemitter3')

function App (options) {
  if (!(this instanceof App)) {
    return new App(options)
  }
  Emitter.call(this, options)
  this.cache = {}
}

util.inherits(App, Emitter)

App.prototype.set = function set (key, value) {
  this.emit('set', key, value)
  this.cache[key] = value
  return this
}

App.prototype.del = function del (key) {
  this.emit('del', key)
  if (!key) {
    this.cache = {}
    return this
  }
  delete this.cache[key]
  return this
}

App.prototype.get = function get (key) {
  this.emit('get', key)
  return this.cache[key]
}

var app = new App({context: {foo: 'bar'}})
app
  .on('set', fn)
  .on('get', fn)
  .on('del', fn)

and all of the listeners would have {foo: 'bar'} context.

For more useful example you can see async-control's test.js, run it and look for after all output. Users can't pass context to each hook, or at least it's not their job, and that's not the logic. They may want to use and modify this context in the hooks, so they can manually pass to every listener method (on/off/once).

Hope understand it. I was about to publish one more emitter which do the job that way, and it's not with browser in mind and it's not compatible with node api. (and it's not needed to be, in my case). But also this package is pretty fast and we need speed.

Lightweight and fast are good, but if it doesn't do what I want, I can't use this. Can you do a simple "comparison" chart for eventemitter2 and eventemitter?

Currently, I'm looking for wildcard support, which seems is not supported.

Perhaps I'm just doing something wrong, but in my current usage of EE3 (which is awesome, by the way!), whenever I try to invoke .emit() with a custom context by using Foo.emit.call(someContext, arg1, arg2, ...), I get some unexpected behavior in my event handlers.

Any guidance/feedback appreciated.

Hey! I was wondering if there was anyway currently to remove an eventListener after a certain period of time. The use case could be where I've set a user's ID as an event name event.on(user_id, doSmth()) and Im waiting on the user to reply me, on which I will emit the ID. However if the user does not reply after a certain duration say 30mins, the eventListener will be removed

Version 1.2.2 of pre-commit just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As pre-commit is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Hi, not sure if this is a bug or if I do something wrong. Before upgrading to 2.0.0 everything worked fine. Am extending a class with eventemitter3 like this:

function MyClass(){...}
MyClass.prototype = Object.create(EventEmitter.prototype);
MyClass.prototype.constructor = MyClass;

MyClass.prototype.someMethod = function(){
    this.emit('notify');
}

Now listening to the notify event throws an error:

var mv = new MyClass();
mc.on('notify', handleNotify); 
// -> Uncaught TypeError: Cannot read property 'notify' of undefined
// ( _events is undefined in EventEmitter.prototype.on )

Are you going to send patch into node/io.js?

This module in browser assumes the window.module is defined, but it isn't in our case. We don't use any fancy require systems (as our build system does the heavy work on that for us) but like to use this for our events (because, ofcourse!).

Would it be a good idea to check for module to exist. Like most node/browser modules do? Or more preferably force people into a certain workflow?

I'd like to know before even thinking of creating a pull :)

Version 2.6.1 of webpack just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As webpack is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

I'm trying to extend my coffeescript class with EventEmitter, but only accessible property is _events.
No other methods are available after extending this object.

Here is my code which is working:

`EventEmitter = require('eventemitter3')

module.exports = (ngModule) ->
item = null

Store = new EventEmitter()
_.extend Store,
  getItem: -> item

return Store`

And this is what I'm trying to accomplish:

`
class Store extends EventEmitter

  @item = null

  getItem: =>
    @item

return new Store()`

It doesn't have properties like emit, on, off etc., Just _events.

As per Nodejs EventEmitter documentation for removeListener function:

removeListener will remove, at most, one instance of a listener from the listener array. If any single listener has been added multiple times to the listener array for the specified eventName, then removeListener must be called multiple times to remove each instance.

eventEmitter3 removeListener implementation however seems to be removing all the subscriptions for a given eventName and listener function. Following is a sample code to reproduce the issue.

var emitter = new window.EventEmitter();
var fn = function(){ alert("called");}

//add fn listener twice for event1
emitter.on("event1", fn);
emitter.on("event1", fn);

//try removing one listener
emitter.removeListener("event1",fn);

//expected: fn should get called once
//actual: fn doesn't get called
emitter.emit("event1");

Hello,
https://github.com/3rd-Eden/EventEmitter3/blob/master/index.js#L42
Optimization (avoiding apply use) are made if there is only one listener. This does not make sense to me.

Version 2.4.1 of webpack just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As webpack is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

It has been a while since #60 and #54 have been merged. There are some nice performance improvements in master waiting to be released.

@3rd-Eden are you ok with cutting [email protected]?

& I don't get why you check if fn is defined in the loop.
see https://github.com/3rd-Eden/EventEmitter3/blob/master/index.js#L130

Maybe something like this is more optimized:

  if (fn) {
    for (var i = listeners.length, found = false; i >0; --i) { // LIFO
      if (found || listeners[i] !== fn) { // remove only one listener
        events.push(listeners[i]);
      } else {
        found = true;
      }
    }
    this._events[event] = events;
  }
  else this._events[event] = null;

Version 3.4.2 of mocha just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As mocha is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 2.3.3 of webpack just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As webpack is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Your readme suggests that this is an alternative to eventemitter2, but it sounds like you aren't implementing any extended features at all. In fact, this has less features than node's EventEmitter by design. So please remove the part about this being at all related to eventemitter2.

Version 2.5.1 of webpack just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As webpack is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Hey, a lot of the performance optimizations here assume things about V8 that are no longer true with TurboFan.

This issue is to track and remove those eventually.

Ignoring errors and compiling will work fine. Is the definition file incorrect?

I do not remember exactly, but in previous versions there were no errors.

Does the prefix really necessary? How to deal with with event type Symbol

The index.d.ts exports class EventEmitter as named exports but whereas the actual index.js exports it as default using module.exports = EventEmitter

This was something I figured would be a good time to ask for as well since you are probably working hard on the next major version with the previous enhancement just implemented.

So what I am looking for is something fast and simple that lets me know if there is > 0 listeners for a particular event.

Here is what I've done so far, be kind ;)
https://github.com/GoodBoyDigital/pixi.js/blob/dev/src/ticker/Ticker.js#L6-L18

Basically, the listeners method was just too much overhead for what I would be using it for, and I could keep the count myself, but that get's more difficult with once method.

May I please have your thoughts?

http-party/node-http-proxy#809

Haven't looked at why this happened but its a good thing version was pinned and you guys bumped to 1.0.0 :). People only ran into this issue because they were on an old version of http-proxy.

Hi, using systemjs and es6 classes i tried to make this with my class:

import {EventEmitter} from 'eventemitter3';

export class Fetch extends EventEmitter {
    // code here....
}

But i got this error in console:
Error: TypeError: Super expression must either be null or a function, not object(…)

Is it possibile that eventemitter3 is not compatible with es6 classes?

I am adding flow definitions to flow-typed.
Could you take a look?

When you only want to include the index.js in your html, to use it without node/browserify, it will give an error because module is not defined.

The way other libraries (like eventemitter2) handle this is checking if module or exports exist:
http://stackoverflow.com/questions/12571737/module-exports-client-side
http://www.matteoagosti.com/blog/2013/02/24/writing-javascript-modules-for-both-browser-and-node/

Hi, @pyrotechnick , @lpinca

I tried to use this module as a drop-in replacement for the native one and ended up with this error message:

(node:6956) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 change listeners added. Use emitter.setMaxListeners() to increase limit

With the native solution this error is gone. I am now using NodejS 7

Does the v2 include any breaking, non backwards-compatible changes?
I'm using EE3 in several projects and now I need to upgrade to v2 in all of them to avoid having 2 versions in the same bundle.

They did exist in 2.0.2.

It seems strange/unexpected to me that I can install this package via npm, and even run npm install inside it to get all the dev-dependencies, but because test.js is npm ignored running the typical npm test fails.

Would you consider perhaps having npm install somehow pull down test.js (and any other necessary files) from github, or at a minimum throwing a warning that it's missing and that npm test will thus not run?

Or perhaps the package.json distributed via npm itself should be stripped of all that non-relevant stuff that the npm package itself will never be able to use?

Would be nice for the benchmarks, tests, etc, not to get installed.

Is it worth adding a CDN link to the README?

Hi,

I'm not sure if it's intended behaviour so please correct me if I'm wrong.
I understand that dispatching other actions from given action is wrong, but right now I've something like this:

AuthenticationAction -> 
dispatch(AuthenticationSuccess) -> 
update(CurrentUserStore) -> 
emit('change') -> 
ListComponent: componentWillMount triggers action to request items from server
Uncaught Error: Cannot dispatch an action ('LIST_LOAD') while another action ('AUTHENTICATE_SUCCESS') is being dispatched

I can get around that problem by using:

setTimeout(function(){
  this.emit('change');
}.bind(this));

in the CurrentUserStore but I'm not sure if it's a good solution. Wouldn't it be better if we've captured change event from stores and after they all have finished updating, iterate over changed stores?

module.exports = EventEmitter;

It doesn't work, module is undefined.

Patch:

//
// Expose the module.
//
(module || {}).exports = EventEmitter;

Why did You write this way?

EventEmitter.prototype.emit = function emit(event, a1, a2, a3, a4, a5) {
  var evt = prefix ? prefix + event : event;

  if (!this._events || !this._events[evt]) return false;

  var listeners = this._events[evt]
    , len = arguments.length
    , args
    , i;

  if ('function' === typeof listeners.fn) {
    if (listeners.once) this.removeListener(event, listeners.fn, undefined, true);

    switch (len) {
      case 1: return listeners.fn.call(listeners.context), true;
      case 2: return listeners.fn.call(listeners.context, a1), true;
      case 3: return listeners.fn.call(listeners.context, a1, a2), true;
      case 4: return listeners.fn.call(listeners.context, a1, a2, a3), true;
      case 5: return listeners.fn.call(listeners.context, a1, a2, a3, a4), true;
      case 6: return listeners.fn.call(listeners.context, a1, a2, a3, a4, a5), true;
    }

    for (i = 1, args = new Array(len -1); i < len; i++) {
      args[i - 1] = arguments[i];
    }

    listeners.fn.apply(listeners.context, args);
  } else {
    var length = listeners.length
      , j;

    for (i = 0; i < length; i++) {
      if (listeners[i].once) this.removeListener(event, listeners[i].fn, undefined, true);

      switch (len) {
        case 1: listeners[i].fn.call(listeners[i].context); break;
        case 2: listeners[i].fn.call(listeners[i].context, a1); break;
        case 3: listeners[i].fn.call(listeners[i].context, a1, a2); break;
        default:
          if (!args) for (j = 1, args = new Array(len -1); j < len; j++) {
            args[j - 1] = arguments[j];
          }

          listeners[i].fn.apply(listeners[i].context, args);
      }
    }
  }

  return true;
};

Instead write -

function emit (event/*, ...rest*/) {
    var length = arguments.length;
    var args = (Array.prototype.slice.call(arguments, 1));

    listeners.fn.apply(context, args);
}

When doing:

if (server.listeners('error').length){ }

because of

EventEmitter.prototype.listeners = function listeners(event) {
  return Array.apply(this, this._events[event] || []);
};

throws a TypeError: Cannot read property 'error' of undefined if no bound event exists. With the original eventemitter, I don't get this error, because it makes some sanity checks before attempting to return the array of listeners.

If I'm refactoring code, and I accidentally comment out an event handler, e.g., say I've:

// const handleFoo = () => { /* ... */ }

myEmitter.on('foo', handleFoo);

Then later when I call:

myEmitter.on('foo', () => { console.log('on foo'); });

Then that call will fail with an error of:

this._events[evt].push is not a function

The simple fix would be to add a bail out / error in EventEmitter.prototype.on that checks that the function it's going to add as a callback is actually a function.

https://wzrd.in/standalone/eventemitter3@latest
The browserified bundle actually doesn't seems to export that function name properly.

This works: var a = new eventemitter3()
this doesn't: var a = new EventEmitter()
neither: var a = require('eventemitter3') being a standalone module, no require is needed.

If we can add listeners by context we should be able to remove by them as well.

This was brought up by this issue:
pixijs/pixijs#1693.

Here is an example of how my lib originally based on Backbone.Events accomplishes this:
https://github.com/drkibitz/qi-events/blob/master/src/index.js#L153-L181
It is also unit tested:
https://github.com/drkibitz/qi-events/blob/master/test/unit/Events.test.js#L202-L239

For me this is a fundamental problem with the ee3 api, and would like to get this in. I am will to contribute and create a PR if needed, thanks.

This API doesn't seem to be supported, why?

@trevnorris pointed out to me that binding to the eventemitter context when calling listener functions causes V8 to hold back on a lot of its optimisations and is way slower.

You could still pass the context as last argument, but I don't see the big usage for getting the context anyways, as when you start listening for an event - in almost all of the cases - you have the eventemitter instance in your scope anyways.

I wonder if it makes sense to remove component.json and bower.json from the root of this repo. Component is no longer maintained and Bower recommends to use yarn + webpack.

Would this be too disruptive? Is the UMD build from unpkg.com CDN enough?

Version 10.3.2 of nyc just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As nyc is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Hi guys,
Can we please include a proper way to define the module, so it actually starts working everywhere? Something like:

(function (name, definition){
    if (typeof define === 'function'){ // AMD
        define(definition);
    } else if (typeof module !== 'undefined' && module.exports) { // Node.js
        module.exports = definition(require);
    } else { // Browser
        var theModule = definition(), global = this, old = global[name];
        theModule.noConflict = function () {
            global[name] = old;
            return theModule;
        };
        global[name] = theModule;
    }
})('EventEmitter3', function (require, exports, module) {
    // the real code here
});

Right now I cannot use it withing AMD environment, which is a total shame!

If you don't like it - just tweak the code a little, like not adding it to the global scope if it's for the browser, and just return the newly defined "module", so that very simple and basic usage can be achieved with no pollution at all.

I would like to see typescript typing information included into npm package. That would make using this library a lot easier in typescript projects. Currently there exists external type definition for this package, but it is out of date and seems to be incorrect. Of course I could contribute to that type definition, but first I would like to ask if package maintainers might be interested in including type definition in package itself. It would be the cleanest and most convenient way of handling typings for package users.
I would be happy to create PR with necessary changes if this is something package maintainers are interested in.