3 ms·

I think that's a bit negative. Yes, they don't provide important things like identifying variables as you mention, but mapping back to the original source is st

by azakai 13y ago

I think that's a bit negative. Yes, they don't provide important things like identifying variables as you mention, but mapping back to the original source is still extremely useful by itself.

kevingadd 13y ago
A large subset of scenarios do not have a 1-1 mapping of output source to input source. Source maps have been represented as a solution to various debugging woes when they strictly seem to handle 1-1 mapping and nothing else. The linked blog post addresses this to a degree, and that's why I think it's great to see it cover this topic. The misleading presentation of source map features is problematic because I think it leads end-users of transpilers to believe that it will solve their problems and ask for it as a feature addition, when in reality it won't do them much good. I do think the people who specced source maps were correct to start with the narrowest possible feature set, though, even if the resulting spec seems strangely micro-optimized in ways that make it much harder to generate than it would be otherwise.
- cromwellian 13y ago
  I think the motivation of the original design was probably efficiently. Google ships many very large JS bundles, Gmail, Calendar, G+, etc. I think Gmail may be on the order of 4Mb obfuscated. Loading up large maps would hog tons of memory and be slow. SourceMaps originally came out of a need for better stack trace deobfuscation I think, use inside of debuggers came way later. I am totally onboard with fixing the deficiencies of the current format to make debugging better. Now that neither Firefox nor Chrome support the JSVM hooks we needed to make GWT DevMode work, we are stuck with sourcemaps for debugging, and Java programmers are not pleased with having to look at mangled symbol names in their scopes and watches. I don't really care what the format of the file is, as long as it preserves a number of features: 1) can still ship and debug 'stripped' binaries, doing deobfuscation offline on the server 2) memory and network efficient. Don't make my JS debugger freeze loading these things in, or each up hundreds of megabytes 3) supports cascading and merging. We have hybrid apps at Google, that is, apps that are compiled with multiple transpilers and linked together. We 'merge' sourcemaps from these together in a unified sourcemap. So whatever the future format is, it should support efficient composition.
  - kevingadd 13y ago
    Yeah, I think they did a decent job of optimizing for constraints, other than the use of JSON and VLQ (Honestly, protobufs would have been a universally better encoding for this, since they provide fixed-size records you can seek through and already offer a superior variable-length encoding.) I think extending what we already have instead of reinventing the format is smart. All of your concerns listed at the end are things I care about too.
- skybrian 13y ago
  It's many to one, actually. Each range of JavaScript has to be generated by only one line of source, but in the other direction there's no constraint. So a single position in source could map to multiple character locations in JavaScript (for example, due to inlining). However, I don't believe browser debuggers handle this properly yet. The way to understand the spec is that they wanted to enable breakpoints. Breakpoints in debuggers such as Chrome are line-oriented. If the debugger can find the corresponding position in JavaScript and set a breakpoint, the sourcemap did its job. However, there are other issues with sourcemapped breakpoints: https://code.google.com/p/chromium/issues/detail?id=333569 https://code.google.com/p/chromium/issues/detail?id=333569
cromwellian 13y ago
What's missing is identifying scopes. They do identify variables today, they just only identify global symbols. Not locals or heap properties. This critically used in a large number of Google products to huge extent. We globally trap all unhandled exceptions, and deobfuscate those exceptions using sourcemaps before they go into an automated bug triage system. The issue of handling locals and properties can be fixed without overhauling the format. Storing the debugging information in the JS itself would remove the ability to ship stripped binaries and be a non-starter for production apps.

by azakai 13y ago

I think that's a bit negative. Yes, they don't provide important things like identifying variables as you mention, but mapping back to the original source is still extremely useful by itself.

kevingadd 13y ago

A large subset of scenarios do not have a 1-1 mapping of output source to input source. Source maps have been represented as a solution to various debugging woes when they strictly seem to handle 1-1 mapping and nothing else. The linked blog post addresses this to a degree, and that's why I think it's great to see it cover this topic. The misleading presentation of source map features is problematic because I think it leads end-users of transpilers to believe that it will solve their problems and ask for it as a feature addition, when in reality it won't do them much good. I do think the people who specced source maps were correct to start with the narrowest possible feature set, though, even if the resulting spec seems strangely micro-optimized in ways that make it much harder to generate than it would be otherwise.

cromwellian 13y ago
I think the motivation of the original design was probably efficiently. Google ships many very large JS bundles, Gmail, Calendar, G+, etc. I think Gmail may be on the order of 4Mb obfuscated. Loading up large maps would hog tons of memory and be slow. SourceMaps originally came out of a need for better stack trace deobfuscation I think, use inside of debuggers came way later. I am totally onboard with fixing the deficiencies of the current format to make debugging better. Now that neither Firefox nor Chrome support the JSVM hooks we needed to make GWT DevMode work, we are stuck with sourcemaps for debugging, and Java programmers are not pleased with having to look at mangled symbol names in their scopes and watches. I don't really care what the format of the file is, as long as it preserves a number of features: 1) can still ship and debug 'stripped' binaries, doing deobfuscation offline on the server 2) memory and network efficient. Don't make my JS debugger freeze loading these things in, or each up hundreds of megabytes 3) supports cascading and merging. We have hybrid apps at Google, that is, apps that are compiled with multiple transpilers and linked together. We 'merge' sourcemaps from these together in a unified sourcemap. So whatever the future format is, it should support efficient composition.
- kevingadd 13y ago
  Yeah, I think they did a decent job of optimizing for constraints, other than the use of JSON and VLQ (Honestly, protobufs would have been a universally better encoding for this, since they provide fixed-size records you can seek through and already offer a superior variable-length encoding.) I think extending what we already have instead of reinventing the format is smart. All of your concerns listed at the end are things I care about too.
skybrian 13y ago
It's many to one, actually. Each range of JavaScript has to be generated by only one line of source, but in the other direction there's no constraint. So a single position in source could map to multiple character locations in JavaScript (for example, due to inlining). However, I don't believe browser debuggers handle this properly yet. The way to understand the spec is that they wanted to enable breakpoints. Breakpoints in debuggers such as Chrome are line-oriented. If the debugger can find the corresponding position in JavaScript and set a breakpoint, the sourcemap did its job. However, there are other issues with sourcemapped breakpoints: https://code.google.com/p/chromium/issues/detail?id=333569 https://code.google.com/p/chromium/issues/detail?id=333569

cromwellian 13y ago

What's missing is identifying scopes. They do identify variables today, they just only identify global symbols. Not locals or heap properties. This critically used in a large number of Google products to huge extent. We globally trap all unhandled exceptions, and deobfuscate those exceptions using sourcemaps before they go into an automated bug triage system. The issue of handling locals and properties can be fixed without overhauling the format. Storing the debugging information in the JS itself would remove the ability to ship stripped binaries and be a non-starter for production apps.