Skip to content
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

Merged
merged 5 commits into from
May 6, 2015
Merged

Better sourcemap handling #65

merged 5 commits into from
May 6, 2015

Conversation

Rich-Harris
Copy link
Contributor

See #64... this is all WIP. The SOURCEMAP_PROCESS_START and SOURCEMAP_PROCESS_COMPLETE event codes depend on an as-yet unreleased version of gobble-cli

@Rich-Harris
Copy link
Contributor Author

Actually I'll merge this straight in, otherwise this could become a monster. It makes two changes:

  • it creates a .final directory, copied from the last stage of the build, and writes the flattened sourcemaps to it. This might fix Issue watching already minified files #63 though I haven't looked into it yet. Either way it's the correct behaviour
  • only .js and .css files have their sourcemaps flattened. Other file types are assumed not to have sourcemaps. This speeds things up considerably in some cases

Rich-Harris added a commit that referenced this pull request May 6, 2015
@Rich-Harris Rich-Harris merged commit 4a0355b into master May 6, 2015
@Rich-Harris Rich-Harris deleted the better-sourcemaps-wip branch May 6, 2015 14:40
@evs-chris
Copy link
Contributor

I like the idea of a final directory. It seems like it would pull serve and build closer together. How do you feel about having a sort of special observer just for the final product?

@Rich-Harris
Copy link
Contributor Author

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.

@Rich-Harris
Copy link
Contributor Author

@evs-chris I had a crack at implementing lazy sourcemaps: #71

@Rich-Harris
Copy link
Contributor Author

Should mention: it doesn't need the .final directory any more, because when building/watching it can write sourcemaps straight to the destination directory, and when it's serving it doesn't write flattened sourcemaps to disk at all. So there's no need to symlink/copy everything into a final directory between the last transformer and the ultimate destination.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants