This is the fault of your implementation, not the pattern. Event types (names) should be enums, not arbitrary strings. This makes it very easy to change the way the code reads if the meaning of the event slightly changes, and equally easy to obfuscate the event key in a production build.

You would need a static js compiler to type check the enum. So that's an extra step. This doesn't happen in Java or C, but browser based event models (the topic of the post) are almost always strings. Most front end shops choose this implementation. You could add that step to your build, sure, but in. Lot of cases the app is already interpreted so there is no "build" per se. Who else has seen this?

You can make them properties on a global object, so that using an invalid event name is at least a runtime error (when you try to bind to an undefined event) rather than being mystified about why the event never triggers.

You still need a runtime test to find the error though, which I why manual QA is required.

So code an eventing system that throws exceptions when an event name that isn't registered is used... It's not difficult; it's what I use in all my JavaScript.

The jQuery route is also interesting, as it registers events as actual methods. So trying to call an event that doesn't exist will, again, throw an exception.