Proxy process.on("exit") to avoid MaxListenersExceededWarning

[mike-marcacci]

This fixes #30, working around node's MaxListenersExceededWarning by creating a "proxy" event emitter to forward exit events.

This is a more concise alternative to #34.

[gabegorelick]

@mike-marcacci Won't you now just get the MaxListenersExceededWarning on the processExitProxy object instead of on process? That's somewhat better since you can call setMaxListeners(Infinity) on this proxy object, but I don't see that in this PR.

[mike-marcacci]

@gabegorelick 🤦🏼 indeed haha; that is now fixed in the PR.

[jaydenseric]

@mike-marcacci may I suggest doing regular commits when working on the PR, vs force-pushes? That way the email notifications, PR history, etc. has the changes as incremental diffs which is easier to follow. You can always squash the PR to a single commit when merging it if you prefer a single commit on master afterwards.

[mike-marcacci]

@jaydenseric yes indeed, that would probably be helpful here. I'm in the habit of staging larger PRs with distinct, logical commits (as opposed to "historical" commits), which can then be reviewed more easily. But for smaller PRs, yes I definitely agree: keeping the history greatly helps collaboration 👍🏼

[jaydenseric]

I don’t have the bandwidth right now to go too deep into reviewing this, but the approach looks good to me.

[jaydenseric]

It would be absurd, but I wonder what would happen if you constructed a new fs-capacitor ReadStream after the process exit event has been fired, say, within an exit event handler.

[mike-marcacci]

That's a good question with a pretty straightforward answer actually: nothing 🙃

Node will not schedule another event frame when this event is fired, and so only synchronous code gets executed in these handlers.