Make watchman-processor librar-ish

[ventuno]

Most npm packages that run as a binary have also the ability to be imported in a project and run as a library.
It would be great if watchman-processor worked the same way, so that developers could extend its functionality and create new UIs or integrate it with other tools if needed. See watchman-processor-tray-icon [1] as an example that uses watchman-processor as a library to create a bitbar plugin [2] and send notifications to the notification center (see also this better implementation of a tray icon using electron [3]).

Changes summary:

1. Modify WatchmanProcessor.ts to emit node events instead of calling directly Terminal.ts;
2. In bin/watchman-processor listen to these events and call the corresponding Terminal.ts methods;
3. Update tests accordingly.

@markis, let me know if you like this idea, I think it would be a pretty powerful extension to this great package. More than happy to switch to more a appropriate architecture if needed, I kind of wanted to write down the code to convey the idea better.

[1] https://github.com/ventuno/watchman-processor-tray-icon/blob/f73d873463a3f682c649a1ca80b8b76cb2cbb11e/bitbar-plugin.js
[2] https://github.com/matryer/bitbar#writing-plugins
[3] ventuno/watchman-processor-tray-icon#1

[coveralls]

Coverage remained the same at 100.0% when pulling 874258e on ventuno:make-watchman-processor-librar-ish into 98052a5 on markis:master.

[markis]

Wow, cool! I love the idea of integrating this with bitbar.

I am not a fan of magic strings and I would not want the internals of this to be dependent on them. It inevitably leads to this: f7d9326#diff-0ba683aead6f4617bf0950fcc8b0913dL72

I think all of this could have been done simply by building a different "terminal" class and just injecting it instead of rewiring all the internals to use events.

[ventuno]

Thanks @markis how do you suggest I proceed? How would the alternative "terminal" class emit events to the outside world and how do developers inject it?
Eventing/hooks seemed the most standard approach.
I could expose event strings as constants and improved tests should protect from "magic" strings error.

[ventuno]

@markis I spent some more time on this to use an enum instead of just strings to trigger/listen to events. I tried to improve tests, but due the overall asynchronicity of the whole program it's a little difficult to do so without introducing flakiness. Let me know what you think.

[ventuno]

@markis ping?

[ventuno]

Sure @markis, just wanted to know if this had still a chance :-). Good luck with your sale!

[ventuno]

Hey @markis any chance you could get to this? Maybe in the new year?