Improve the merging of two sourcemaps

[mariusGundersen]

It seems like the applySourceMap method of the source-map project produces the minimum of the two provided source-maps, which is probably not what most people expect it to do (for example, concat and uglify don't work well together).

I'm working on an improved algorithm for applying one sourcemap to an existing sourcemap, which this project might be better of using.

[OliverJAsh]

I'm very interested in this after spending many hours trying to produce a correct source map when piping a file through babel and then uglify: terinjokes/gulp-uglify#105 (comment).

[qraynaud]

👍 I lost hours because of this too believing my code for the regexp-sourcemap package was wrong when it was applySourceMaps that broke everything in my gulp module...

[jvilk]

I wrote a Grunt task that does this, and it works fairly well on my own projects. You could potentially adapt it for vinyl-sourcemaps-apply if it seems suitable. Just note the limitations.

[qraynaud]

@floridoo : what are your thoughts on this?

[elliot-nelson]

I was disappointed to run into this today; I have been debugging some pretty basic custom plugins for gulp and finally realized that this module doesn't do what I thought it did.

For example, even a very simple gulpfile chain (src -> gulp-sourcemaps -> gulp-typescript -> gulp-ifdef) produces broken sourcemaps, because "applySourceMap" doesn't actually chain "ts->js" and "transform js" source maps together, it just stuffs both the .ts and .js source mappings into a big list.

The link John posted above looks like it does it "correctly", but I'd much prefer a tool that lets me continually update the inline source map for each file correctly, rather than having to write out individual maps for each step in the chain and merge them all at the end.

---

At risk of stating the obvious, just for anyone finding this in the future, the issue is that if you take two example source maps, let's say, one for ts->js and one that further modifies the js:

A: {
  sources: ['example.ts'],
  file: 'example.js',
  mappings: {
    source: 'example.ts',
    generatedLine: 57, generatedColumn: 0,
    originalLine: 30, originalColumn: 0
  }
}

B: {
  sources: ['example.js'],
  file: 'example.js',
  mappings: {
    source: 'example.js',
    generatedLine: 52, generatedColumn: 0,
    originalLine: 57, originalColumn: 0
  }
}

What you want if you apply source map B to source map A is this final result:

GOOD: {
  sources: ['example.ts'],
  file: 'example.js',
  mappings: {
    source: 'example.ts',
    generatedLine: 52, generatedColumn: 0,
    originalLine: 30, originalColumn: 0
  }
}

Instead, what the current implementation gives you is this, which the browser generally has no idea what to do with:

BAD: {
  sources: ['example.ts', 'example.js'],
  file: 'example.js',
  mappings: {
    source: 'example.ts',
    generatedLine: 57, generatedColumn: 0,
    originalLine: 30, originalColumn: 0
  },
  mappings: {
    source: 'example.js',
    generatedLine: 52, generatedColumn: 0,
    originalLine: 57, originalColumn: 0
  }
}

[elliot-nelson]

Another option could be that I am simply doing it wrong; for example, I'm assuming it's safe (that is, a no-op) to write out "no change" source maps that map line 1 to line 1, line 2 to line 2, etc. An example is https://github.com/elliot-nelson/gulp-strip-import-export/blob/master/index.js#L19.

However, maybe because I am writing out a "no-change" source map with higher resolution than a previous source map, I'm accidentally forcing the bad behavior I see in my post above.