Stack trace column number incorrect if error is thrown on line 1

[rogierschouten]

It seems that node internally prepends some code to wrap a script into a module. However, it fails to correct for this in the stack traces of any errors that occur on line 1 of a script. This manifests itself e.g. in uglified files where EVERYTHING is on line 1 of the script. This renders sourcemaps useless.

Example:

throw new Error("bla");

Output (note the column number of the first stack frame is larger than the line in the code):

c:\issue.js:1
(function (exports, require, module, __filename, __dirname) { throw new Error(
                                                                    ^
Error: bla
    at Object.<anonymous> (c:\issue.js:1:69)
    at Module._compile (module.js:456:26)
    at Object.Module._extensions..js (module.js:474:10)
    at Module.load (module.js:356:32)
    at Function.Module._load (module.js:312:12)
    at Function.Module.runMain (module.js:497:10)
    at startup (node.js:119:16)
    at node.js:935:3

[misterdjules]

When you say it renders sourcemaps useless, is it because your source map tool uses column numbers in error messages to map to the original line number in the source?

[rogierschouten]

Yes, a source map translates locations in a target file to locations in the source file. As the stack trace lists the wrong location in the target file, then the location in the source file is also incorrect. And even though the difference in the target file location is only 63 characters, the difference in source file location might be much much more. Think of e.g. TypeScript files compiled to JavaScript files and then bundled together in a single javascript file and then uglified. A difference of a single character might land you in an entirely different source file.

[misterdjules]

@rogierschouten Thank you for the clarification. I'm familiar with the concept of source maps, less with their practical use. I had always thought about source maps as using only line numbers to do the actual mapping, but after thinking about it more than 2 seconds it seems obvious that column numbers also need to be used.

My next question to try to assess how many users it affects is: in what context do you use uglyfied/minified JavaScript code for a Node.js application? Is it because you're sharing code that also runs in the browser and that code needs to be as small as possible to minimize the data that is transmitted over the wire?

Thank you again!

[insidewhy]

I've just hit this issue... very very surprising!

I minified some code using "uglify" and the output from uglify consists of all your code on line 1. So of course... you never get correct stack traces.

[insidewhy]

In my case I don't actually need uglified code for node.js though, I was just using node.js to test the principle. Sent me on a several hour long hunt into the internals of both the mozilla source map library and uglify-js only to get here.

This error... oh boy... so glad I found this issue though. Thank you so much for raising it.

[rogierschouten]

Yeah debugging source maps is a pain... I still have half a mind to make an on-line source maps reader just for this type of thing

[lydell]

No need to make an online source maps reader. There already is one: http://sokra.github.io/source-map-visualization/

[insidewhy]

That visualiser is so great/useful.

[brendanashworth]

Thanks for opening this issue up - this issue tracker is becoming an archive, so I'll close this issue in favor of nodejs/node#2860.