Flatten sourcemaps lazily when serving

[Rich-Harris]

As mentioned here, it'd be great if the sourcemap flattening process happened in the background when gobble is serving. Rather than proactively searching all the built files to see if they have sourcemap chains that need flattening, gobble could wait for a request from the browser and do it then, which would provide a nice boost to perceived speed with sacrificing any of that sourcemappy goodness.

For gobble watch and gobble build it would still need to be proactive though.

[martypdx]

I just upgraded what I could figure out to upgrade in the ractive project with the hopes of being able to use source maps again. Seems to be working better, though occasionally still end up looking at:

// Please wait a bit.
// Compiled script is not shown while source map is being loaded!

if debugger breaks early in the loading. I bring this up because I don't know if this would be a more regular thing if they were loaded lazily, or whether this would solve the issue.

EDIT: Sourcemaps still don't have any legs. They work for about 5-10 minutes, then nothing but above. But then if fiddle with new browser tab or gobble restart, works again for a little while.

[Rich-Harris]

I suppose you'd be more likely to hit 'please wait a bit', but the total time (from invalidation to sourcemapped debugging) would be the same or less, so I reckon it's a net plus.

They work for about 5-10 minutes, then nothing but above

That's weird, even by the Twilight Zone-esque standards of this stuff. It might possibly because of something else I've noticed (or rather, my long-suffering colleagues have complained about) - sometimes if you reload the page while a build is happening, you get half a build, when you should get the 'gobbling' page. Haven't had a chance to try and reliably reproduce it though. Does that sound plausible?

[martypdx]

No, don't get a gobble page, everything builds and runs fine, it just doesn't load the sourcemaps.

Easiest way is to turn Pause on all Exceptions on, then run a specific unit test in ractive where there's an error in the called ractive code.

I suspect it may have to do with chrome too and how it caches things.

[martypdx]

This doesn't seem good:

[Rich-Harris]

Wow, no that doesn't look good at all. Is that something that only happens after the task has been running a while? How big is the .map file?

[martypdx]

So this is one that actually "worked':

Let me see if I can get it not working for size compare.

[martypdx]

Here's one where it has stalled:

then after stepping through some breakpoints when it's complete it shows as downloaded:

[martypdx]

oh, take a look at the trailing "livereload" requests. They don't exist on the one that works

[Rich-Harris]

Only 2.1 minutes? Don't know what you're complaining about...

Are there steps you can take to reliably get it into a broken state? Or is it just a case of continually changing source files until something snaps?

[martypdx]

Only 2.1 minutes? Don't know what you're complaining about...

well that's my time hanging out with debugger paused. so it gives me opportunity to get coffee or have smoke in the mean time 😉

Are there steps you can take to reliably get it into a broken state? Or is it just a case of continually changing source files until something snaps?

usually I'm running a single test in single test file - so I'm repetitively doing that. Once it's borked, I have to create a new tab in chrome (or turn off source maps and use ractive-legacy directly)

[martypdx]

oh, maybe we're hitting chrome's 6 max connections. how are you serving the static files?

[Rich-Harris]

Crudely. Should probably be streaming, for one thing. I'd assumed that there wasn't a problem with max connections though, because I'm sure it's served more than 6 files simultaneously in the past - I could be wrong though

[martypdx]

I'm down with bare metal http. :) Just an idea that maybe there not being "close" somehow or otherwise hand-shaking with chrome on this - because it's EXACTLY the seventh thing (not counting the already served .html file).

Let me try removing the simulant ref and try a test page that doesn't need it.

[martypdx]

http://stackoverflow.com/questions/25078753/sourcemap-request-pending-when-breakpoint-is-hit-is-there-a-way-to-force-a-prel

[Rich-Harris]

I'm experiencing the same thing. So Chrome can't ingest a sourcemap while the debugger is paused? That seems totally nuts. Anyway, I've implemented lazy sourcemaps (#71) and it seems to be working - doesn't do anything for the debugger issue though.

[martypdx]

Would it make more sense to not combine the sourcemaps into one uber file but rather serve them independently?

[Rich-Harris]

When I first started tinkering around with this stuff I assumed that browsers would be smart enough to handle multiple levels of sourcemaps, but they're not - if foo.js has a foo.js.map sourcemap that lists bar.js as a source, the browser will stop at bar.js even if there's a bar.js.map file that lists baz.js and so on. Which is why sorcery exists - you have to flatten all the chains leading up to foo.js into a single foo.js.map. One .js/.css file, one map. No way around it as far as I can tell.