Sourcemaps Are Invalid

[chadhietala]

Preamble

Lets talk about sourcemaps 😄 😢 ! As you may know sourcemaps can be awesome when they are produced correctly and also a huge time suck when you realize that sourcemaps are wrong and just pointing to the wrong place in code. Due to the relative encoding of sourcemaps, the first invalid mapping affects all mappings from that point forward, leading to break points and exceptions being in the wrong place. This means that if any actor in your build pipeline is being a bad tenant and produces invalid maps, you're pretty much hosed.

Yea Yea Yea I Know

At this point I feel like everyone in the JS community is at an awkward party where no one wants to admit they are having less than a stellar time.

In other words, I have no idea how people are successfully using sourcemaps on any project of scale. A lot of the times browser vendors take the brunt of this as people just think that the decoding of the map in the browser is wrong. However, I feel like this is more of a wide spread epidemic across the JavaScript tools ecosystem due to the nature of how sourcemaps must be encoded. That being said we can use tools like sourcemap-validator to validate that our tools are producing valid sourcemaps upon release, giving us much more confidence that we're not poisoning the well.

Things We Have Identified

At LinkedIn we use Babel on basically every new product at this point, which is great. However, sourcemap issues have come up multiple times in internal tickets, specifically our SREs (Site Reliability Engineers) and people on-call would like to use sourcemaps when things go sideways in production. We have noticed that out of the box Babel is producing invalid sourcemaps (reproduction). @stefanpenner, @krisselden, @rwjblue and I have noticed that there are some issues in propagating location information back to the AST when mangled symbols and whitespace are introduced via plugins or normalization post-transform.

Plan

We (LinkedIn) can likely allocate a good amount of time on fixing this problem in the last part of this year. From our point of view, we feel like we need to do a bit more root cause analysis and identify exactly where the maps become invalid. As part of the analysis we would like to introduce more thorough testing of the sourcemap generation in the test harness. Once we have identified those areas and added utilities to the test harness, we would like to propose creating a quest issue for both babel internals and vendored plugins to farm out the work to people in the community. In the Ember community we have had a lot of luck doing these large, yet mechanical, types of burn down lists as long as the issue provides a lot of detail as to what to do.

Let me know what you think 😄

[hzoo]

Yeah that sounds great! Sourcemaps are great and everyone has had a bad experience due to the lack of testing at each level so it seems brittle.

We (LinkedIn) can likely allocate a good amount of time on fixing this problem in the last part of this year.

That sounds great and I can totally support that effort! We can do a ghangout for this too if you'd like. We can also do a #sourcemaps room in slack if that helps (https://babeljs.slack.com/messages/sourcemaps). Also I remember another tool: http://sokra.github.io/source-map-visualization?

thorough testing of the sourcemap generation in the test harness

That would be great.

Yes creating the milestone and issue is definetely a great step forward, thanks for making this!! I'm really optimistic at what's going to happen with this effort from y'all 😄

[nehaleem]

That would be freaking awesome! We are struggling with sourcemaps too and we are forced to shut them off for this moment, because of wrong breakpoint mapping.

[CharlieGreenman]

I was wondering if anyone has officially picked up this issue at this time?

[gdborton]

@chadhietala Has any of this work been picked up?

[webern]

Status?

[stefanpenner]

@chadhietala Has any of this work been picked up?

Unfortunately, we were unable to find the required resourcing :(

[hzoo]

FYI @loganfsmyth has landed some fixes (not sure if completely related) to sourcetypes on both 6.x and 7.x as part of firefox devtools work #7761, backport is #7812

[loganfsmyth]

That PR is specifically around inputSourceMaps, so I'm not sure it affects this specific case, but that fix should still be a big improvement.

That said, the error that the example repository throws is fixed by ben-ng/sourcemap-validator#12 which was also part of my devtools work.

Given that, I'm actually not sure if there's other work for us to do here. It really depends on how aggressive sourcemap-validator is, and what counts as "bad" in its eyes. It's entirely possible there are just places where we'll disagree.