-
Notifications
You must be signed in to change notification settings - Fork 3
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
Support for Sourcemaps #6
Comments
It's not entirely clear to me what you are requesting. Do you want Jint to be able to map source locations to the original file which the executed JS was generated from (for example, to print the original source locations in a stack trace)? Or do you want the parser to be able to generate a source map for the files fed to it? |
My request asks for mapping source locations to the original file from which the executed JS was generated, sorry for not being clear in the OP. The idea is that along with the JS script Acornima / Jint would also accept the source map file and then locations could be mapped. |
https://github.com/sleeuwen/sourcemaps |
This looks good, had no idea such a package already exists, thanks. |
For reference, this is my project: https://github.com/scgm0/Book-of-Genesis |
Ok, so we're talking about executed JS here. In that case, however, I don't think Acornima has anything to do with this request. This library is a parser (like Esprima), not an execution engine (like Jint). In other words, this library can transform the JS code you feed to it into an abstract syntax tree, which includes the location of the syntax elements. But that's the execution engine's task to use this location information and look up the original file and location from the source map when it prints a stack trace, does step-by-step debugging, etc. So, I think, this feature should be requested for the execution engine you use. As @scgm0 pointed out, the other piece of the puzzle, the source map parser/lookup is already available, so probably it wouldn't be a very hard task to implement it. |
Just one more thought: maybe you don't even want the execution engine to provide source map parsing and translation out of the box. It would be enough if the execution engine gave you an extension point which it used for resolving source locations to original files whenever it's necessary. For example, it could take a callback in its options so you could provide whatever source location resolution method you want. |
Thanks for the pointers @adams85 @scgm0. Currently, Jint already reports the location of the current statement when debugging via |
This was previously requested in Esprima - sebastienros/esprima-dotnet#198
The use case is simple - to make debugging of transpiled files (typically TS->JS) possible.
The text was updated successfully, but these errors were encountered: