Builder should support source maps

[graouts]

Source maps are extremely useful for debugging JavaScript or CSS code that was concatenated from individual source files, much like what the builder does in component. I think component ought to support the generation of source maps so that using component doesn't have the penalty of more painful debugging.

[tj]

yup this is definitely on the list

[bestander]

+1 for that

[ForbesLindesay]

👍

[karlbohlmark]

It would even be good enough to just have a --debug build that would output the css as one css file with a list of imports and add sourceURL mappings for the javascript.

Actually, isn't //@ sourceURL even better than source maps, since it preserves the inspectability of variables?

[ForbesLindesay]

We could do that but it only works when you eval the code as a string so we'd have to use new Function with the source of each module as a string.

[ForbesLindesay]

Also source map should support inspecting variables provided you don't minify the code anyway.

On the other hand //@ sourceURL is way simpler so:

I quite like the idea of simply replacing https://github.com/component/builder.js/blob/master/lib/builder.js#L645-L647 with:

if (devBuild) {
  return 'require.register("' + file + '", new Function("module", "exports", "require", '
    + JSON.stringify(js + '\n//@ sourceURL=' + file)
    + '));';
} else {
  //old code...
}

Which would at least show up as separate files in the scripts pane on Google Chrome. We then just need to pass the devBuild option through from some parent location.

I'm not too fussed about the style sheets tbh.

[karlbohlmark]

Yeah, that's all I need with regards to the javascript. Actually I don't get why they didn't include variable inspection in the source maps spec; it makes it pretty much useless when you have //@ sourceURL as a much simpler alternative.

[ForbesLindesay]

I'm pretty sure variable inspection works fine with source maps. It just doesn't 'map' the variable names for you. If you don't do any variable re-naming then it's not a problem. What that means is that source-maps are fine for concatenation, fine for languages that compile to JavaScript (e.g. CoffeeScript) but not perfect for minified files. If you're trying to use a source-map to debug a minified file you're doing something wrong anyway though.

SourceURL is of no use with compile-to-js languages, it doesn't actually load that file, all you do is say "this bit of code has a name". If you add a sourceURL to code generated by CoffeeScript, it's still going to look like JavaScript. Adding sourceURL's to a JavaScript file directly is also no-use as it doesn't do anything. SourceURL is intended for debugging code that's generated on the client side or loaded from somewhere other than a script tag. i.e. code passed to eval and code passed to new Function.

To Summarise:

SourceMap

Compile to JS languages, file-concatenaters/module-systems and limited support for minified files

sourceURL

Module systems provided they 'eval' the code, dynamic script loaders that involve 'eval'ing code

Both serve very different purposes, it just happens that there's a tiny bit of overlap, which means that we could use either, although SourceMap should give us marginally better results because it would mean we wouldn't have (function (module, exports, require) {\n and \n//@ sourceURL=foo.js\n}) either side of our scripts. The down side is that it's newer and support seems to be a little bit flakier. I still have yet to see a good demo of it that's not trying to work with minified code though, and I suspect it works a lot better when it's not with minified code.

[karlbohlmark]

Yes, thanks for the clarification.

I use sourceURL for my compiled and combined coffeescript to split it back up into files i dev tools. While you are probably correct that variable inspection will work for build processes not involving any obfuscating of names, the coffeescript compiler actually does introduce quite a few new names that would not be inspectable in current source maps implementations.

For this reason, I much prefer debugging the compiled javascript with sourceURL annotations to using source maps, since I find debugging without inspection mostly pointless.

[ForbesLindesay]

CoffeeScript produces new names, but it doesn't mangle old ones, so all the old names would still be inspect-able. What you're doing only really works because JavaScript is actually an easier language to read and understand than CoffeeScript. With CoffeeScript I think I'm not uncommon in the fact that if I have to edit it, I edit the generated JavaScript and back-port my changes to CoffeeScript.

[tj]

ef85f97