Andy Wermke

Awesome stuff. Was the last thing I replied to last night and the first thing I saw today, so didn't have time to get my hands dirty yet. > if...

Nice idea. But since the debugger would not be included (?) in the user's build process we would have to provide an easy way to tell it which PostCSS plugins...

Maybe. I have never written an Atom plugin before, but it shouldn''t be too hard, I guess.

Hi @ctaepper! I was just writing some instructions when it appeared to me that right now the postcss-debug code might not yet handle the dynamic nature of webpack incl. changing...

Sure, let's keep it open as a reminder for now. Btw: Thanks! I am glad about your feedback, too. I always start by the assumption that it's easy to solve...

I am still thinking about it... I see multiple problems for the webpack scenario (which is a shame, since I like webpack and many people use it). Like - when...

Serving the debugger is not the problem. But updating the debugger view when the dev-server re-compiles a changed css file is. Plus: If a file is processed by two different...

Didn't forget you. I think I know how to implement better and more dynamical webpack support, but it's not going to be as nice as I would like it to...

Hey @georanma. Yeah, there is not much going on in this repo. If it's a relatively simple change to upgrade to the latest PostCSS version, I am happy to merge...

True. I also thought about that, but there are some detail issues: Do we color by - relative time (slowest/fastest for _current file_) - relative time (slowest/fastest for _all files_)...