Terser compression messes with return position in sourcemaps

[bmeurer]

Bug report or Feature request?

This is not a bug strictly speaking, insofar as the sourcemap is still okay, but it leads to a really bad developer experience with compressed builds.

Version (complete output of terser -V or specific git commit)

terser 5.12.0

Complete CLI command or minify() options used

terser --source-map url=out.js.map -o out.js --compress -- input.js

terser input

I have uploaded a repro to https://github.com/bmeurer/terser-return-position which illustrates the full problem. The input is fairly trivial:

function testFunction() {
        let obj = {x: 1};
        console.log(obj);
        console.log(obj.x);
}

terser output or error

The output is

function testFunction(){let obj={x:1};console.log(obj),console.log(obj.x)}
//# sourceMappingURL=out.js.map

with out.js.map being

{"version":3,"sources":["input.js"],"names":["testFunction","obj","x","console","log"],"mappings":"AAAA,SAASA,eACR,IAAIC,IAAM,CAACC,EAAG,GACdC,QAAQC,IAAIH,KACZE,QAAQC,IAAIH,IAAIC"}

Expected result

Check out the sourcemap visualization result, it clearly shows that the closing } of the function statement is combined with the .x) into a single range in the sourcemap:

This leads to a confusing developer experience, where in DevTools it looks like the program is paused on the o.x property access, when it really is paused on the return position of the function (which the JS engine reports via the closing } of the function statement):

It'd be great if terser would not merge the closing '}' with previous ranges.

[jridgewell]

Copying the @hbenl's comment from #1210 (comment):

Yes, it is (sorry, I had searched for duplicates before opening this issue but hadn't found that one). However, that issue doesn't quite capture how irritating the missing end-of-function-body mapping can become. Here's a loom of one of my replay.io colleagues getting pretty confused by this: https://www.loom.com/share/9bba477eeea04393ba4c699bfe12b3f6 And here's a recording that lets you see the issue yourself in our time-travel debugger: https://app.replay.io/recording/replay-of-appreplayio--a18983a0-f3f5-4e80-b9aa-7160a65304f5 I've added 2 comments to that recording showing places in our code where I've recently noticed this issue, if you click on one of the comments, then switch to the debugger panel and click on "Step Over" you can see how the execution seems to end up at the wrong line. This has come up repeatedly, so we really hope that you can add this end-of-function-body mapping.