Skip to content
This repository has been archived by the owner on May 19, 2018. It is now read-only.

Question on class/method/property location data when it has decorator(s) #694

Closed
JamesHenry opened this issue Aug 25, 2017 · 11 comments
Closed

Comments

@JamesHenry
Copy link
Member

JamesHenry commented Aug 25, 2017

I find it a little unintuitive that if you apply a decorator to a method (or other target construct such as a class), the method's location data does not include the decorator, given that the decorators: [] array is a property of the node.

Both the TypeScript and Flow parsers (the only others I believe support decorators) behave differently to Babylon here, their relevant method node location includes the decorator content.

I could not find any guidance on location data within https://github.com/tc39/proposal-decorators

Was this behaviour explicitly discussed and decided on in Babylon? Are there other precedents of nested nodes "overflowing" their parents?

Example Code

class Other {
    @foo({ baz: true })
    static get bar() { return this._bar; }
}

Live example: http://astexplorer.net/#/gist/c7692dd145ef9aaa2c9600f976257a2a/bf55ed4537b7520a6c19045d7e9fa4e6f3f11d14

...take a look at the highlighted method for Bablyon vs TypeScript and Flow (and the location data in the AST of course).

@hzoo
Copy link
Member

hzoo commented Aug 25, 2017

Hey @JamesHenry! We really appreciate you taking the time to report an issue. The collaborators
on this project attempt to help as many people as possible, but we're a limited number of volunteers,
so it's possible this won't be addressed swiftly.

If you need any help, or just have general Babel or JavaScript questions, we have a vibrant Slack
community that typically always has someone willing to help. You can sign-up here
for an invite.

@existentialism
Copy link
Member

@JamesHenry IIRC this is fixed in decorators2

@JamesHenry
Copy link
Member Author

JamesHenry commented Aug 25, 2017

Indeed it is, thanks, @existentialism!

Updating my parser config to use decorators2 instead of decorators fixes it, however it clashes quite badly with the TypeScript support, because TS has more options for things like parameter decorators than decorators2 allows (cc @andy-ms)

Is there any reason not to apply the location fix to the decorators plugin as well? That works perfectly with TypeScript as far as I can tell. (I'm happy to submit the PR if it will be accepted)

@JamesHenry JamesHenry changed the title Question on method location data when it has decorator(s) Question on class/method/property location data when it has decorator(s) Aug 25, 2017
@JamesHenry
Copy link
Member Author

(Updated the description a bit as this does not just apply to method decorators)

@existentialism
Copy link
Member

@JamesHenry not sure how others feel re: making changes to old decorator plugin, but I'm fine with it... and nice side effect: it'll help remove some comment-related hacking in prettier as well.

@JamesHenry
Copy link
Member Author

Yep, and I'm sure @vjeux will be happy about that 😄

@hzoo @danez How do you feel about me adding the location fix to the original decorators plugin?

@JamesHenry
Copy link
Member Author

@vjeux
Copy link

vjeux commented Aug 25, 2017

I'd be super happy indeed :p

@jridgewell
Copy link
Member

Go ahead.

@JamesHenry
Copy link
Member Author

Thanks @jridgewell, PR opened here #699

@JamesHenry
Copy link
Member Author

The PR was merged! Thanks all

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

No branches or pull requests

5 participants