WIP: Add new plugin (classAndFieldDecorators) for Stage-2 decorators proposal - #236

Will this be breaking for cases like

class Foo {
    @decorators['foo']
    bar(){}
}

?

Will this be breaking for cases like

It should be, based on my reading of the spec (good catch, updated to breaking in the OP). Having said that, this is a case that this branch currently parses incorrectly. I'll work on fixing that. Fixed

Breaking changes are something we need to figure out in Babel and Babylon. This kind of thing makes me wonder if we should add a decorators2016 plugin and leave the current one as-is or something, since we can't really make breaking changes to the existing logic and bumping to 7.x would have its own set of downsides.

How about classAndFieldDecorators? That way we're not tying it to a year.

The other question, though, would be what should we do in the scenario that a user has both enabled (could easily happen now that we support * for all plugins)? With your example code above, one version of the draft (the older one) would allow @decorators['foo'] to parse, but the newest draft would consider that a syntax error. Would be a bit more straight-forward without the * option, unfortunately. This is addressed by this PR

Should we make a new major version and remove the old decorator plugin and instead create the new ones? I think we also have other stuff that is breaking. node 4, deprecated plugins

I think this PR is incorrect because

1. @decorators['foo'] is allowed
2. It doesn't allow decorating computed properties

If my reading of the spec is correct, then

1. Only @foo.bar.baz or @foo.bar.baz(a,b,c) syntax should be allowed where foo,bar, or baz can
   be any IdentifierName, and
2. Decorating computed properties should be legal

Going to close in favor of #587!