SourceMapGenerator.prototype.applySourceMap generates incorrect source map when source map to apply contains name entries in a filename not found in the source map to apply to.

[insidewhy]

Say there's two SourceMapConsumers, M1 and M2, M2 has file = F1 and many name entries.

If each of the name entries in M2 is also found in the file F1 within M1 then you can apply M2 on top of M1 just fine.

However if any of the name entries within M2 don't have a corresponding name entry within M1 under F1 then the entries (relating to the names from F1) in the source map resulting from the application will be incorrect. If M1 doesn't even have any F1 entries then the resulting source map will contain entries pointing to F1 when F1 shouldn't even exist within the source map!

I guess it's necessary to detect names that don't exist in the destination map and remove them from the resulting source map, using the identifier locations instead.

[lydell]

Here's a related test if it helps:

source-map/test/source-map/test-source-map-generator.js

Line 471 in 22388a5

exports['test applySourceMap name handling'] = function (assert, util) {

[insidewhy]

Thanks, hm that looks like the case I'm describing.

I have a case here where applying a source map M1 for file F3 containing source files F1 and F2 onto another M2 with file F3 leads to a map M3 with file F3 and sources F1, F2 and F3. In the resulting source map I have a source entry for F3 that shouldn't be there. The only way this test differs from those that works is that F3 doesn't exist as a source in the source map and that M2 contains names in F3.

[insidewhy]

The reason for my bug eventually turned out to be: nodejs/node-v0.x-archive#9445

The F3 entries are fine... they just represent lines that have no mapping in the original source file, I thought the source maps were off due to that bug screwing with stack traces of uglified code on line 1.