Implement: decorator proposal #2645
Comments
Decorating a methodBabel 6.0.13 //.babelrc
{
"plugins": [
"syntax-decorators",
"transform-decorators"
]
}Original function tester(a, b, c) {
return c;
}
class Test {
@tester
test(a) {
return a;
}
}Babelled function tester(a, b, c) {
return c;
}
class Test {}
Test;
|
Decorating a class (with class)Babel 6.0.13 //.babelrc
{
"plugins": [
"syntax-decorators",
"transform-decorators"
]
}function classTester(target) {
}
function tester(a, b, c) {
return c;
}
@classTester
class Test {
@tester
test(a) {
return a;
}
} |
|
For methods: In babel-plugin-transform-decorators Line 41: Remove the decorator methods Line 47: ??? I don't found a similar code in babel 5.x :/ |
|
The Babel issue tracker is not for support queries. |
https://github.com/babel/babel/blob/master/CHANGELOG.md#6119 6.1.19
A lot of people are subscribing to this (thank you Phabricator!) so I figure I'll give some more context and an update. Decorators were removed in Babel 6 because the decorator proposal has vastly changed from the version that's in Babel 5. I could implement the old proposal in Babel 6 which would make existing Babel 5 decorator code work but when I updated the transformer for the new version of the proposal, your code would break and I'd be violating semver. I'm not willing to do another major bump either as majors in a project like Babel are extremely difficult to coordinate as there's so many integrations using it.
@sebmck would you be open to publishing a nonkosher version of the plugin -- for example, The major use case I'm familiar with is React Native, which is shipping with Babel 6 shortly (the next release candidate is going out in the next few days). RN core doesn't use Babel 5 decorators but many npm packages in the ecosystem do because RN's packager encourages adoption of ES2015 and beyond by making it easy to add Babel 5 flags / Babel 6 plugins. All this is to say that temporarily supporting old decorators in Babel 6 in a way that doesn't break semver will ease the transition to Babel 6 for folks using decorators.
@ide It's just a lot of work. I can look into doing a straight port of the Babel 5 classes plugin and releasing it as a plugin though as that should be fairly easy which I guess is basically what you're asking.
@sebmck a port of the old plugin is exactly what I think would help Babel 5 users migrate a codebase with (old) decorators to use Babel 6. I don't want this to become a pain for you so if it's easy to port the old plugin that's great. Otherwise I can look into porting it myself but I think you'd be much faster at it.
Where is decorators proposal changed, where issues, discuss about it? I try to google it, but i can't find anything, except old proposal: https://github.com/wycats/javascript-decorators
Kinda interested in this as well, what has changed?
@sebmck I'd be happy to sponsor a quick port of the Babel 5 classes plugin to Babel 6.2, just to get tons of projects using
If I'm not mistaken, these are the changes to the decorator proposal to which @sebmck is referring: cc @rthewhite
I'm going to work on porting the Babel 5 decorators plugin to Babel 6 since there's high demand for it. If you have experience implementing Babel plugins and want to help out find me on Reactiflux (keep this Phabricator task free of noise).
@ide if you are porting the Babel 5 decorators to Babel 6 as a stop gap, I collected some links to resources and problems to do so in the other task (https://phabricator.babeljs.io/T2702) when I was considering doing it myself. Finger in the air estimate...it is probably 1 to 3 days of work to implement and port all of the tests given the complexity.
@kmalakoff I started working on it but I'm probably not going to get it done quickly because as you mentioned the learning curve is high for writing a significant plugin like this one. Porting the Babel 5 functionality is definitely what I would put my support behind because it facilitates the upgrade to Babel 6. A migration plan from Babel 5 --> Babel 6 + old decorators --> Babel 6 + new decorators is probably best for the community and it lets people upgrade to Babel 6 while authors of decorator libraries work on updating their packages. Plus this week's release of React Native will ship with Babel 6 so several early adopters aren't going to be able to test the latest RN on projects using decorators. I put up an airpair request for help with the plugin but I'd rather give $300 to someone who does a good job writing the plugin since I think it'd be faster that way. It's probably less than you'd be paid if formally contracting to write it but you'd be doing it first and foremost for open source and the external community.
Hey everyone, I just want to say that we're well aware of how much of a pain the lack of decorators in 6.x has been. Unfortunately, things have taken a bit longer than originally hoped. Rather than try to have Babel 6 support both decorator proposals, the intention is still for Babel 6 to implement the new proposal once it has been officially presented to TC39. That said, your comments have definitely been heard, so I've put together a plugin that does its best to implement Babel 5 style decorators in Babel 6: https://www.npmjs.com/package/babel-plugin-transform-decorators-legacy One important limitation, which is noted in the README, is that the decorators on class properties can only mutate the initializer itself, not
@loganfsmyth Thanks for the plugin, man. It works awesome. But there's a little gotcha, if you're using the "transform-class-properties" in your project as well, make sure to put it BEFORE the "transform-decorators-legacy" value in your .babelrc plugins configuration. If you don't do that the "transform-class-properties" plugin gets lost and introduces a undefined variable, which creates an error ("_undefined is not defined"). But again, many thanks!
@m4n3z40 Sounds like https://phabricator.babeljs.io/T2983 for the Not 100% on the ordering, essentially if you want to be able to decorate class properties the decorator plugin should be run before the class property plugin, though perhaps that requires the fix mentioned above.
@loganfsmyth thank you so much for this. I copied the code from the issue you mentioned and the I'm not totally sure precisely on what this entails: I'm assuming this falls outside the support target or is this a bug?
HUGE thanks to @loganfsmyth for putting this together. I was hesitant from upgrading to React Native 0.16 to lose all my decorators.
I've fixed the limitations I originally mentioned about https://www.npmjs.com/package/babel-plugin-transform-decorators-legacy and I'd now expect decorators to work pretty much the same as they did in Babel 5 if you use that transform.
Lowering the priority on this given that it's not a high priority since we don't even have a spec to build yet, and the legacy plugin should alleviate most of the rush.
Does the legacy plugin work with Babel 6? If so, which one is it?
Yes, it is a Babel 6 plugin. I'm not sure what you mean by "which one". I linked to it above, you'd install it like any other Babel plugin.
@loganfsmyth I tried on the day of the latest release a few days ago, but had to stop because I couldn't get it to work with mobservable. I'm trying again today and trying to track down the problems.... First problem: If I manually add but I run into a second problem: The world decorator is added, but the hello one is missing from the class decoration section. So it looks like there is a change / bug in how decorators handle class properties...(other more simple ones like
First thanks for the legacy plugin. Secondly, do you know if the official presentation has a date? (or is attached to some known milestone)?
@kmalakoff Could you report your issue on the github project for @AshCoolman I don't know the specifics, sorry. I think it'll essentially be "when wycats feels the proposal is ready".
@loganfsmyth done (loganfsmyth/babel-plugin-transform-decorators-legacy#13). You bring up a good point...people will who subscribed to this issue when it was called "Fix decorators" (or who were merged in from the other issue related to decorator support which is where I was added from: https://phabricator.babeljs.io/T2702) would be very interested in knowing about potential bugs....I have probably spent cumulatively 16 hours upgrading to and reverting from Babel 6 due to decorator support / issues...you can see that I really want to upgrade! My thinking on decorators and this issue...I assume that the new proposal could be stuck in committee for a long time and I need to just find a pragmatic solution to migrating to Babel 6 (I'm still on Babel 5 due to decorator issues). I've been watching this issue for updates since I got here from where you pointed me from Github (started: 69fb185#commitcomment-14865033, then https://phabricator.babeljs.io/T2702, then here, and now being directed here: https://github.com/loganfsmyth/babel-plugin-transform-decorators-legacy). I would love a single place to get updates on legacy compatibility issues which I assumed (until you just mentioned it) that it was here... Maybe it would be better to open a new issue called "Implement new decorator proposal when finalized" and keep this issue focussed on "Fix decorators" (I'm not interested in tracking "Implement new decorator proposal when finalized"). Alternatively, you could create an issue called "Fix decorators" (I'd be interested in knowing about any other issues people encounter) or make it official that this issue is now only for the future decorator spec and people who are not interested in it should unsubscribe (which is sounds like this issue has morphed into). Sorry for the verbose response, just trying to make things totally clear since I'm assuming I'm not the only person who might have been merged into this issue which may not quite be a match for what we are looking for...based on the original purpose of helping people who are using decorators migrate to Babel 6, I suspect most people are here for current support of decorators in Babel 6 instead of the future spec...but I could be wrong... I really appreciate you carrying the torch on this!
If you'd like to track issues with I'd recommend that people following this issue for the "Fix decorators" rather than the "Reimplement decorator proposal" case unsubscribe since that should now be fully addressed by
@loganfsmyth @babel team I think I good old warning, backed by a well-written issue / blog post explaining the problems would have been a much, much better choice.
@Download it is not so much the features that have been thrown out/rescheduled until the spec gets fixed, but rather the obnoxious smaller issues with that 6.x+ release. I for my part think that they were just perfload testing the phabricator instance and the community 😁
@silkentrance @Download There are certainly other higher-priority tasks, but my previous statements are not incorrect, we are indeed waiting on the spec to stabilize. I will definitely admit that it has taken longer for that to happen then any of us were expecting, which is why we decided to go forward with the @Download If you are referring to https://github.com/wycats/javascript-decorators/blob/master/README.md, mind the note at the top:
The in-progress decorator specification in https://github.com/wycats/javascript-decorators/blob/master/interop/reusability.md is the newer one and is quite different from the old one. Existing decorators would not work unchanged.
Turning on transform-decorators-legacy will cause errors if you use class properties in a specific way. This will say that Foo is undefined while trying to evaluate 'Foo.SECOND'. Without the decorators-legacy plugin this works.
@mattinsler This thread is about the implementation of
The v6 docs say that decorators are supported, but they're not. A few words about this in the docs would have saved me about 3 hours of wasted time today. Please can someone merge this PR to update the docs: babel/website#765
I've seen recent activity in the new-ish TC39 repo, so maybe this might stabilize soon and be re-implemented? By the way, it's going to require a major overhaul for most decorators, because the interfaces are very different. Note that the === Property/Method Decorators === Property and method decorators don't accept the descriptor directly, but in a wrapper object now. They accept a MemberDescriptor and return a MemberDescriptor.
=== Class Decorators === Class decorators no longer take the class itself, but a descriptor consisting of the class, its parent class (i.e. `extends Parent) if one exists, and a set of MemberDescriptors on the class.
And yes, Angular, Aurelia, and many others will need to be updated for this. (They may end up at least temporarily supporting both during the transition.) TypeScript can always make the types union types instead, to ease their transition. But regardless, it'll break a lot of things, simply because quite a few people jumped the gun and embraced decorators a little too early.
Thanks for info @isiahmeadows Am I got it right, there is no access to class itself in property/method decorator now?
From the looks of it, class and property decorators have advanced to stage 2 at TC39: tc39/proposals@97eb62f
Fantastic, I guess this must have been approved in the TC39 meeting this week. Can this now be safely updated in Babel?
I started working on an initial implementation (mostly for even understanding what the new proposal does / allows) here: https://github.com/jkrems/babel-plugin-transform-decorators-stage-2-initial. Very early stage but might be helpful. |
|
Any info when Decorators will be again available in babel? |
|
If we have an update we'll make a comment here - I don't think anyone has time to work on it |
|
@idchlife I'd like to mention that this is not about working on actual Babel plugin or something. There were some questions left, the last update was on July meeting. For the time being, there is an external plugin babel-plugin-transform-decorators-legacy. The thing why it doesn't belong to core repo, because it likely will change, even the |
|
Recently Yehuda said that proposal is waiting for implementations. Symbol unlikely will be changed because a huge part of committee is opposed to sigil swap with private properties. So IMO it's best time to start hacking on this right now :) |
|
I've started working on a new plugin for |
|
Decorators at Stage 2 since January 4th: http://tc39.github.io/proposal-decorators/ |
|
👍 |
|
Please don't +1, it's not going to make it happen any faster/sooner. If you have constructive comments to add you can comment in babel/babylon#236. Going to lock this again until the parser part is done. |
|
@babel-bot move to babel/proposals |
|
Hey @kittens! I've moved your issue to the correct repository. Please make sure to keep an eye on the new issue for the latest information. |
No description provided.
The text was updated successfully, but these errors were encountered: