-
Notifications
You must be signed in to change notification settings - Fork 20
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better sourcemap handling #65
Conversation
Actually I'll merge this straight in, otherwise this could become a monster. It makes two changes:
|
I like the idea of a final directory. It seems like it would pull |
Always in favour of anything that makes code DRYer. One thing I was thinking about though was that it'd be neat if sourcemaps were flattened 'lazily' when serving, i.e. as soon as the build proper has finished, the live reload signal is sent and the project can be served, then either a) sourcemaps are generated on demand (if the user has disabled 'em, or the browser can't use 'em, no need to make 'em) or b) failing that, they're generated in any case, but a request for them stalls until they're ready. That kind of optimisation could make a real difference to perceived performance, and hence developer sanity, and so I reckon it'd be good to make sure that we can accommodate that sort of thing. |
@evs-chris I had a crack at implementing lazy sourcemaps: #71 |
Should mention: it doesn't need the |
See #64... this is all WIP. The
SOURCEMAP_PROCESS_START
andSOURCEMAP_PROCESS_COMPLETE
event codes depend on an as-yet unreleased version of gobble-cli