escodegen Add option to generate code that respects 'loc' info

Add option to generate code that respects 'loc' info

Open jeffmo opened this issue 11 years ago • 10 comments

I currently use esprima + some traversal code that I wrote to transform JS syntax from A -> B. I'd much prefer to simply modify the AST from esprima and feed it to escodegen (rather than mutate a string buffer of the original code as I traverse the tree and find nodes to be transformed), however I really need line numbers to be preserved post-transformation (for purposes of making stack traces sane in prod). Source maps work great in a dev environment, but they're too large to ship in prod for error logging.

Currently escodegen does its own formatting and doesn't attempt to follow line numbers output from esprima when the 'loc' option is turned on, so I decided to see what it would take to add an option do this and I have a [partially complete] branch with several types of statements supported here:

https://github.com/jeffmo/escodegen/tree/preserveLocInfo

I haven't finished it yet because I wanted to check in here to see if this is a change you'd be willing to take if I went through with finishing it out? It adds quite a bit of complexity to the code (byte size will likely increase significantly), but it's toggle-able via an option so perf should only be impacted when the option is on.

May 03 '13 04:05 jeffmo

Looks great! Controlling the format of output code with loc information is very interesting :)

May 03 '13 09:05 Constellation

This would be great for ariya/esrefactor, which currently has to do what @jeffmo describes.

May 03 '13 15:05 michaelficarra

Awesome. Hopefully (time-permitting) I can have something more complete in the next week or two.

May 03 '13 16:05 jeffmo

Hey folks I have started using this feature to add support source maps support for my wisp language. I'll probably submit individual bugs, but I'd like to share main roadblocks I've run into so far:

loc.end does not seems to have much effect on generated maps. In my case this problem even more visible because I have location info on all nodes except primitive types like string and numbers, and since end location is ignored generated map often considers identifier followed by string as a one node. I really wish it was smarter about it.
I'm not sure yet, but I'm under impression that if several different nodes map to the same source location only first occurrence is taken into account. For example (defn identity [x] x) compiles to var identity = function identity(x) return x }; and while I'd expect identity to be mapped to both locations, it only does to the first one.

That being said, I'm very graceful to this project & keep up a good work!

Jun 27 '13 16:06 Gozala

I guess I commented on wrong thread, which brings a question of how that formatting feature behave if node locations are based of non JS file but rather some other language.

Jun 27 '13 21:06 Gozala

This is exactly what I need for the code transformer built into https://github.com/scriby/asyncblock