More fun with sourcemaps

[Rich-Harris]

Automatic sourcemap flattening, introduced in 0.8, is great when it works. When it doesn't work, it's more of a nuisance than anything.

Two problems in particular have become fairly obvious:

• It currently looks at all output files to try to flatten sourcemaps, when it should only really be looking at .js and .css files. (This became painfully clear when gobble tried to find sourcemap comments in several hundred megabytes of images...)
• The trick of storing sourcemaps in memory, rather than with sourceMappingURL comments, doesn't work too well when sourcemap-generating transforms are mixed with non-sourcemap-generating transforms (such as merger nodes, .include() and other built-ins, gobble-derequire and so on), because sorcery can't find the sourcemap. Comments do at least persist across non-sourcemap-generating transform boundaries.

Am playing around with some fixes, all very WIP. Ironically the more I fight this stuff the more convinced I am that automatically flattening sourcemaps is the right thing to do - they're just such a massive pain to set up. Just need to concoct a medicine that isn't worse than the disease.

I suspect #63 is related as well.

[aubergene]

I'm confused as to conceptually what the plan is with sourcemaps. Following the instructions, I've made a straightforward plugin gobble-stylus which returns an object with a map property.

It says

The file, sources and sourcesContent properties of the sourcemap will be filled in by Gobble.

One of my main uses for Stylus is using @require to include other stylus files. Stylus correctly returns a sourcemap which lists the dependencies on the sources property, but when Gobble writes this to the .cache it has replaced sources with just the src path of the file it compiled, which then means sourcemaps don't map back to the original file. All this is even before sorcery gets involved. Could you enlighten me please?