The Road to 1.0

[jayphelps]

Spec compliancy

• [ ] Update to support both the old and new spec (coming in Babel 6)
  • [ ] Waiting on decorators to be implemented in Babel 6
• [ ] Implement backward compatibility, if possible ???

Add the remaining tests

decorators

• [x] autobind
• [x] debounce
• [x] deprecate
• [x] nonconfigurable
• [x] nonenumerable
• [x] override
• [x] readonly
• [x] suppress-warnings

(private/utils)

• [ ] decorate
• [ ] isDescriptor
• [ ] metaFor

Decide if aliases will continue?

I generally do not like aliases. I'd prefer to have all decorators named as a verb and remove the aliases.

• [ ] @​deprecate (alias: @​deprecated)
• [ ] @​mixin (alias: @​mixins)

Slim builds

• [x] Support rollup via jsnext:main
• [ ] Allow imports of each decorator to not pull in entire library for browserify/webpack users. Most likely via postinstall or similar, aliasing files into the package root so they can import autobind from 'core-decorators/autobind.

[sebmck]

I'd recommend not doing a 1.0.0 until Babel 6 as all of your method decorators are going to break probably.

[jayphelps]

@sebmck I quite literally was JUST seeing you mention changes coming in Babel 6 on twitter. Where can I find the spec changes? I don't immediately notice any changes in https://github.com/wycats/javascript-decorators

[sebmck]

https://github.com/wycats/javascript-decorators/pull/36

[jayphelps]

@sebmck gracias good sir.

[yordis]

:+1: for remove the aliases.

[Download]

I'm not fond of aliases either. Having said that, the given example does highlight that currently in Java, @Deprecated is an official annotation provided by the language. Case sensitivity is also an issue here, but my point is that most annotations in Java use nouns i.s.o verbs... And given the declarative 'feel' of decorators, nouns do seem to make sense. @private is also a noun btw, as are @nonconfigurable, @nonenumerable, @readonly and more.

In fact, just for exercise, let me make a list of the decorators from this repo using all nouns:

For Properties and Methods
@readonly
@nonconfigurable
@decorated                     <--

For Properties
@nonenumerable
@lazy                              <--

For Methods
@autobound                   <--
@deprecated                  <-- 
@warningsSuppressed   <--
@enumerable
@overridden                   <--
@debounced                  <--
@throttled                       <--
@timed                           <--

For Classes
@autobound                   <--
@mixin                            (mixin can be both noun and verb)
@argumentsAsserted     <--
@private                         This one will be very ugly as a verb

Thinking about it more, Java mixes nouns and verbs. E.g. @Deprecated v.s. @Override.

I'd say an argument can be made here that it's kinda just a style thing whether to choose nouns or verbs. Some make no sense as verb (@makePrivate? yuck), some look much better as verb, e.g. @override. Some, it's hard to say. @deprecate feels weird, as if it's still about to happen. @deprecated makes much more sense here imho. It's something that happened to something else, in the past. Also @timed feels better to me than @time, it expresses better what it does imho. But again it's taste. So maybe aliases do make sense in these cases. What do you think?

[Download]

I realize I'm probably improperly using the term 'noun'. Sorry about that, English is not my native language. Anyway they are not verbs is what I mean :)

[dongryphon]

+1 for @deprecated over @deprecate

[kevinSuttle]

decorators have now been moved to stage 2. https://github.com/babel/babel.github.io/pull/883

[jayphelps]

@kevinSuttle yup 😄 #84