-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug: Stack traces from CoffeeScript.eval have JS line numbers #5216
Comments
This problem, more importantly (IMO) also shows up with the CLI. #5129 - this issue has been closed unfortunately |
Another approach would be to get Node to report proper line numbers in code with a sourcemap. I recently tried to get source-map-support to do this (optionally in conjunction with babel-plugin-stack-trace-sourcemap), but I couldn't get it to change line numbers at all (though it was clearly engaged, as it printed slightly different stack traces), even for Babel-supported language conversion (I tried JSX -> JS, as well as CS -> JS, with inline sourcemaps). If anyone has more luck with this, it'd be a viable alternative both in my application and in the |
Are you using the |
@GeoffreyBooth I think Babel transpiling only makes things worse. I just tried |
👋 having worked on Istanbul for years, the lack of source-map support in transpiled code was really bugging me, guess what, we've built initial support into Node.js now for this: https://nodejs.org/dist/latest-v12.x/docs/api/cli.html#cli_enable_source_maps I've tested with compiled CoffeeScript code and it works like a charm. There's still some work to be done, would love help and feedback: It's worth noting, I'm not 100% sure how we'd support |
Thank you @bcoe! I saw that PR against Node and I was tentatively hopeful that it might somehow help CoffeeScript 😄 Do you have a demo repo where you can share how you’ve tested it? Something that might help you is the monkey-patching of https://github.com/jashkenas/coffeescript/blob/master/src/coffeescript.coffee#L341-L355 |
One thing I've found - which is substantial but not a silver bullet unfortunately from what I can tell - is that any code in the dependency tree that does: require 'coffeescript' fucks up stack trace line numbers for all other code when the version of |
Found one scenario where you get invalid line numbers. |
In what I believe is a bug, line numbers in stack traces from errors thrown by CoffeeScript code executed via
CoffeeScript.eval()
(in NodeJS) give the JavaScript line numbers instead of the CoffeeScript line numbers.Simple example
The resulting stack trace and initial message uses a line number of 3 (current behavior) instead of 1 (expected behavior):
More real example with filename
In my application, the eval'd string actually comes from a
.coffee
file, and I can get the filename to appear correctly with enough options toCoffeeScript.eval
(though admittedly I don't understand why so many arguments are needed for this to happen), yet the line numbers remain the same.results in:
Workaround
In my application, I constructed a workaround that corrects the line number in the initial message by using
CoffeeScript.compile
to get a source map, looking up/mapping the line number, and modifying the error's stack trace.Proposed Solution
I think it would make sense for
CoffeeScript.eval
to do this kind of mangling of error stack traces. The REPL already does mangling ofSyntaxError
s viahelpers.updateSyntaxError
, and some of this code can probably be shared. (It was the inspiration for my workaround.)Related issues
Possibly related to #5129 and #4645. In particular, errors from the REPL seem to start every error with
repl:2
whereasrepl:1
would make more sense. I believe this is the same issue, so would also get fixed (though REPL seems less important to me).Environment
The text was updated successfully, but these errors were encountered: