singletons that are retroactively turned into EventEmitters should ca…

[ckerr]

This follows up on a discussion that @mgc, @MarshallOfSound, and I had this week tracking down the root of the AutoUpdater error case crash.

First try

At the end of that debugging session we'd decided to defer the singletons' instantiation until after Object.setPrototypeOf(AutoUpdater.prototype, EventEmitter.prototype) was called so that the newly-created AutoUpdater would have its EventEmitter parent fields initialized.

Unfortunately that's not going to work. Calling new AutoUpdater() in JS doesn't actually create a C++ AutoUpdater object because AutoUpdater and the other singletons don't insert a constructor into the JS bindings: (a) it's unnecessary binding code to (b) give clients the ability to create multiple instances of things designed to be singletons. So, while we could add constructor bindings to make this possible, it opens up more potential problems.

Second try

EventEmitter() defers its initialization to an init() helper function, and Samuel suggested that would work as well. I'm going to chalk this up to my inexperience with JS but I wasn't able to get autoUpdater.init() to work (and it is defined a little differently from other members, ie EventEmitter.init = function(){...} vs. EventEmitter.prototype.setMaxLixteners = function(){...}) but IMO this is just as well because the approach I used is cleaner & should work even if Node changes EventEmitter's internals.

Third try

So after much prologue (and more digging and learning how native_mate works), we actually wind up with a pretty small & simple patch. after reparenting the singletons' prototypes, we call the parent's constructor...

[welcome]

💖 Thanks for opening this pull request! 💖

Here is a list of things that will help get it across the finish line:

• Follow the JavaScript, C++, and Python coding style.
• Run npm run lint locally to catch formatting errors earlier.
• Document any user-facing changes you've made following the documentation styleguide.
• Include tests when adding/changing behavior.
• Include screenshots and animated GIFs whenever possible.
  We get a lot of pull requests on this repo, so please be patient and we will get back to you as soon as we can.

[codebytere]

Does this cover all the modules that are EventEmitters?

[ckerr]

Not all the EventEmitters -- just those that have singletons instantiated on the C++ side and passed along the bridge.

EventEmitter subclasses that are designed to be instantiated on the JS side with new Subclass() don't have this problem, so they don't need this explicit workaround

[welcome]

Congrats on merging your first pull request! 🎉🎉🎉

[jkleinsc]

Fixes #10433