HenrikJoreteg
commented
10 years ago Hey Luke if you trust this. Just merge it. If you don't have access I will give it to you.
On Thu, Sep 26, 2013 at 8:10 PM, Luke Karrys notifications@github.com wrote:
This treats the CSS build step exactly like the JS build step. I merged together functions that were now doing the same thing (request handler, preparing bundles, etc). In this way there are separate before steps for JS and CSS. I didn't want a shared handler since then there would have to be some logic to make sure there was an order to JS/CSS building and my before handlers are each very specific (templates before JS and preprocessing before CSS). Also this opened up the opportunity to report CSS build errors to the user in the same way we report JS errors. What I did was a little hacky, but since it is only for development I think it works. Basically if there is an error at some point, then when the JS handler gets called, it will be hijacked and return the error (as a JS string) instead. There is the edgecase of if the JS is already sent and there is a CSS error, it will not be reported to the user. But in my tests the JS build step was always taking longer than CSS (and I was preprocessing a bunch of files) and this is dev only anyway. You can merge this Pull Request by running: git pull https://github.com/lukekarrys/moonboots css-build Or you can view, comment on it, or merge it online at: https://github.com/HenrikJoreteg/moonboots/pull/8 -- Commit Summary --
- same build stuff for css as js
- handle errors for CSS or JS build
- store error in result; better error parsing -- File Changes -- M index.js (256) M readme.md (3) -- Patch Links -- https://github.com/HenrikJoreteg/moonboots/pull/8.patch https://github.com/HenrikJoreteg/moonboots/pull/8.diff
lukekarrys
This treats the CSS build step exactly like the JS build step. I merged together functions that were now doing the same thing (request handler, preparing bundles, etc). In this way there are separate before steps for JS and CSS. I didn't want a shared handler since then there would have to be some logic to make sure there was an order to JS/CSS building and my before handlers are each very specific (templates before JS and preprocessing before CSS).
Also this opened up the opportunity to report CSS build errors to the user in the same way we report JS errors. What I did was a little hacky, but since it is only for development I think it works. Basically if there is an error at some point, then when the JS handler gets called, it will be hijacked and return the error (as a JS string) instead. There is the edgecase of if the JS is already sent and there is a CSS error, it will not be reported to the user. But in my tests the JS build step was always taking longer than CSS (and I was preprocessing a bunch of files) and this is dev only anyway.