Skip to content
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 sourcemaps #5

Open
OliverUv opened this issue Aug 15, 2018 · 3 comments
Open

Support sourcemaps #5

OliverUv opened this issue Aug 15, 2018 · 3 comments

Comments

@OliverUv
Copy link

When running deoptigate on my large project, which has been compiled from TypeScript to JavaScript, I get this:

scrot

The file, and most files that it requires do have inline sourcemaps. Adding support for those could help move these arrows to their correct positions.

Even with this flaw, the tool is really useful already, since I can see the function names referred to on the right hand side for each of the items. Big thanks!

@OliverUv
Copy link
Author

oh, and:

> node --version
v9.4.0
> uname -srvpoi
Linux 4.13.0-43-generic #48-Ubuntu SMP Wed May 16 12:18:48 UTC 2018 x86_64 x86_64 GNU/Linux

Using deoptigate 0.3.0

@thlorenz
Copy link
Owner

I agree that would be a great feature.
However deoptigate doesn't necessarily know how to resolve those easily, all it has are paths to the files that ran.

I don't think it's impossible, but wouldn't be trivial.
Maybe there is a way to tell deoptigate where to look for map files for the files.

Then it still would have to translate where the markers would go (and wouldn't be able to syntax highlight as it only supports JS ATM).

So a pretty large chunk of work .. I'm open to have someone take this on and help where I can.
It would definitely be an interesting feature.

@thlorenz
Copy link
Owner

On the other hand just stripping inline source maps before creating the data file with the included sources should be trivial with convert-source-map.
Would that solve the larger part of your problem?

If so could you take a stab of adding that step as part of file source resolution and file a PR?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants