We will add them when Babel supports them out of the box. The proposal is being updated (has it already been?) and we don't want users to suffer through a breakage caused by this.

IIRC MobX should work fine without decorators. It's just a little bit more verbose.

I would like decorators but I agree with @gaearon . It would be nice to have decorators in React Native too. Decorators are currently at "stage 1" in the ecmascript-standardization process, and it isn't until "stage 3" that all the syntax and semantics are complete, so I think it makes sense to wait. https://github.com/tc39/proposals

Since this seems like a consensus I'll close this. Thanks for kicking off the discussion @kripod!

I know that it may be against the philosophy of the project, but how about adding an opt-in .reactapp.json file which would allow advanced overrides to be made? The overrided configuration should be merged with the original, keeping the features specified by any of the configurations.

Example:

"overrides": {
  "babel": {
    "plugins": ["babel-plugin-transform-decorators-legacy"]
  },
  "eslint": {
    "extends": "airbnb"
  }
}

Sorry, we don't currently plan to support overrides like this. This makes it very hard for us to change the underlying settings and tools. You might have better luck with some of the alternatives listed in README!

For people coming to this thread later—if you use MobX or a similar library, you don’t need decorators. They are just syntax sugar in this case.

Learn more: #214 (comment), #411 (comment).

Decorators are now not a legacy transform (see babel-plugin-transform-decorators) and is a part of babel-preset-stage-2. Now may decorators be added?

@gaearon on a different issue you wrote

We’re happy to support decorators after the spec advances, and they are officially supported in Babel without the -legacy plugin.

Isn't this the case now? Is adding support for decorators now on your agenda?

I'd be comfortable including them once they reach Stage 3. Treating them differently from Class Properties for reasons explained earlier: we dogfood Class Properties and will release a mod if they change.

@kripod , it support reactapp.json to overrides config now??

They are just syntax sugar in this case.

It's almost never just syntax sugar. Syntax can help to inherently reduce the complexity of a program. Reading a program, writing it, understanding it. All of these tasks can be improved in many ways with the right syntax not only reducing errors but also increasing pace.

@gaearon babel seems to now be off the -legacy plugin for 7.0 https://github.com/babel/babel/tree/7.0/packages/babel-plugin-transform-decorators

@gaearon might be the good time to have decorators now 👍

Hi @canercandan, the proposal is still stage-2.
We will probably not consider adding support until they've been in stage-3 for quite some time.

I don't want to eject..

There should be a way to configure CRA without ejecting, and without installing React Super Scripts or similar. We could configure Babel for example, even in an already created app. Maybe creating a config folder and setting the config folder as an env variable should leverage the CRA config.

For anyone reading this in the future, I would like to point out that the decorators spec has changed significantly. I'm really glad we made the decision to not support them at early stage, so users who didn't eject don't need to change their code.

I don't recommend anyone to rely on the legacy decorator transform (that is not part of CRA). See this thread for more info: https://twitter.com/dan_abramov/status/897491076537356288.

An update for MobX: from MobX 4 and onward, it will be a lot more simple to use MobX without decorator syntax. Enabling decorator syntax is no longer required to use decorators. Instead of writing

import { observable } from "mobx" 

class X {
  @observable y = 1
}

One can 'manually' apply the decorators using the decorate utility:

import { decorate, observable } from "mobx" 

class X {
  y = 1
}
decorate(X, { y: observable })

(Cross linking #214, #411 as those are closed, if a maintainer could link back to this comment that would be great :))