Skip to content
Switch branches/tags

Latest commit


Git stats


Failed to load latest commit information.
Latest commit message
Commit time


Responsible publish/subscribe. Hide the event publisher, only exposing the event emitter.

Why is this cool?

Most pub/sub frameworks conflate the role of publisher and emitter. This means that if someone gets ahold of your emitter object, they can not only subscribe to events, but also fake out all other subscribers by emitting an artificial event:

// server.js
process.on("exit", cleanupServerStuff);

// thirdParty.js
// uh oh, now the server stuff's been all cleaned up!

With pubit, the publisher and emitter are separate, allowing you to keep the publisher private while exposing emitter functionality. Here's a hypothetical implementation of a process module using pubit:

var pubit = require("pubit");

var publish = pubit.makeEmitter(exports);

exports.exit = function (exitCode) {
  publish("exit", exitCode);

This module only exports the emitter interface (on, off, and onNext); the publish function is kept private.

Aren't you being paranoid?

There's some argument as to what role encapsulation has to play in JavaScript. Some might say, “if you don't want the event to be emitted outside the emitter … don't emit the event outside the emitter.”

But encapsulation isn't about being paranoid. It's about hiding complexity: exposing a solution, without requiring the consumer to grok the gory details of the problem. An emitter by itself is simple and easy to interface with, but when you add knobs for publishing or introspection, you're no longer solving a problem, but instead creating option paralysis and fragility. Someone should be able to understand that an object emits events, without worrying about who could be publishing those events in the first place.

Pubit is ポカヨケ.

More docs and examples

  • Check out a simple example of using pubit for responsible pub/sub.
  • Be sure to check out the listener helper examples to get a look at a nice feature pubit provides to solve a common use case.
  • If you like that sort of thing, we also have an API reference.
  • Perhaps most educational would be checking out the unit tests—they're very readable, I promise! Run them with npm test if you'd like.


Responsible publish/subscribe. Hide the event publisher, only exposing the event emitter.




No packages published