[V2] Error and Warning Handlers

[bhough]

Given that this is acting as a CSS compiler of sorts, each module should have error/warning handling that informs the user if they have provided the invalid values/syntax/etc... These should only be use in development and will be stripped out by webpack for production.

In my experiments I've been loosely following the formatting used in ELM. So they come out looking sort of like this:

-- Warning: Clear Fix -------------------------------------------------------- mixins/ClearFix.js--

  'clearFix' does not accept a parameter. However, you provided a parameter with a value of 50px.

  'clearFix' simply returns the cross-browser CSS necessary to clear floats and does not require
 any parameters to work.

--------------------------------------------------------------------------------------------------

Would love everyone's thoughts on this.

[mxstbr]

I like having very clear error messages, that could prove important. Let's see what we can do in our build system to strip those out in production but have them in dev!

[ericclemmons]

Setting the bar for error messages would be a huge differentiator for this project.

[ericclemmons]

@bhough Is there a util that structures output like this already, or something we'd invent?

The last one I looked at was:

https://github.com/AriaMinaei/pretty-error

I believe we'd be able to throw an object that contained fields like message (typical Error property) and hint that could be leveraged for special output.

[mxstbr]

Reusing some common util would be great for this, or writing our own in a separate package!

[bhough]

I do like pretty-error's formatting. I'm starting on this issue next, so I will see if it will work with the verbose errors we want to display, if not I like the idea of creating our own @mxstbr.

One of the tricks I wanted to implement with this is to remove this error/warning functionality when the package is built for prod. I imagine that while useful for debugging during development, it would prove to be superfluous code for production. Does that assumption hold up with everyone?

[mxstbr]

Yeah that sounds very reasonable to me!

[bhough]

@mxstbr @nikgraf Question on this. As far as what errors we want to expose in dev/production. Right now I have formatted errors/warnings working in dev and completely disabled in prod (meaning no custom errors are thrown in prod at all). Are we fine with this, or do we want to draw a specific line between for what we leave in prod when it comes to custom errors.

[mxstbr]

That sounds reasonable to me @bhough! Do you have a WIP PR?

[nikgraf]

@bhough good question. It makes sense, but I'm not sure how we deal with inputs that don't make any sense e.g. rgb(66)?