WIP: feature(parser middleware): Add support for processing raw IRC lines.

[jirwin]

This introduces a change that allows users to process any incoming raw
IRC messages before they are passed onto the final message parser.

This adds a few concepts:

• Client.enableParseMiddleware(function): Add a function to the end of
  the middleware chain.
• Client.disableParseMiddleware(function: Removes a function from the
  middleware chain.
• Client.parser: The function that is used to parsed an incoming raw
  IRC message. This is run after all middlewares have completed.
  Defaults to the message parser at ./lib/parse_message.js. Custom
  parsers must return an object that matches what the existing parser
  returns.

As an example, the stripColors feature has been moved to a parser middleware.

Also tests.

Also some various cleanup I came across while working on this.

[ghost]

Is there a module that does this? I'd be surprised if not. If not, I would consider extracting it into one.

[jirwin]

Looks like https://www.npmjs.com/package/irc-colors does everything irc colors. Probably worthwhile switching to that, but out of scope for this PR. I'll open an issue.

[jirwin]

I opened an issue @ #297

[ghost]

A more general comment: could you please rebase this to one commit, off of current master with my recent pull req?

[hnry]

Just my 2 cents, I don't think the 'enableParseMiddleware' and 'disableParseMiddleware' should be on the Client object. Because I'd rather the Client object not be overloaded with APIs and it can slightly encourages weird stuff to happen if a user uses those functions while running.

So I'd rather see Client._parseMiddlewares be passed in on creation: var client = new Client(server, nick, { middleware: [customMiddleware, customMiddleware2, IRC.parser] })

The Client should have no idea how to add or disable middleware personally, it doesn't belong in the 'Client'.

And for users who want the option of modifying the middleware chain at runtime, it's still possible. But the API doesn't help them do it. Since no many people will want it, and it's kind of dangerous if they don't understand what they're doing.

And about the Client object, some people may have multiple clients, so you have to consider how it'll look in the end to create multiple Clients and how light these Client objects are.

[hnry]

Oh and the plus side of making the middleware chain be passed in on Client creation is that you can always assume no passed in argument equals use the default node-irc middlewares for parsing. Which keeps the overall API simpler, otherwise with the enableParseMiddleware way it gets trickier to figure out if the user wants node-irc to just use the default middlewares, because you never know when they'll call it.

[hnry]

And also can we have the default middleware chain be [stripColors, parseMessage, higherLevelEmitters], higherLevelEmitters being the .on 'join' , 'message', 'part', etc.

It's there by default to maintain the API most people are use to now, but we should have the option to remove it for people who don't want that.

[jirwin]

Thanks for the feedback. This is just the first step into making things a little less monolithic and providing a little more control to the user. I'll continue working on this.

[ghost]

I think this looks good so far! I want to test it out in real world usage. If it's still a WIP, are there other things you're planning on adding? Should I merge this as-is after testing it for a little bit, or wait?

[jirwin]

I'd like to take @LoveBear's feedback into consideration, as a first step. I think that defining the parser middleware being defined at the time of Client instantiation is a good idea, but want to make sure we get the interface right.

Don't merge this for now. Hopefully I'll be able to push changes later this evening.

[jirwin]

@LoveBear I incorporated your feedback.

I still need to refactor the rest of the tests to use fixtures, and this should be ready to go.