## 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](https://www.npmjs.com/package/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](https://github.com/chadhietala/babel-le-broken)). @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](https://github.com/emberjs/ember.js/issues/13127) 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