Flow: ES7 decorator support or a way to ignore the error

[bsr203]

Hi,

ES7 decorators cannot be used with flow. Wish there is a way to continue using flow but may just ignore this feature. Currently it stops the server with error.

Unexpected token ILLEGAL

Error is pointing to the @ character

@connectToStores(getState, TestStore)
export default class MyComponent extends React.Component {

[nmn]

https://github.com/facebook/flow/issues/454#issuecomment-119524118

[majhork]

this might work for you:

var deco = function(target, name, descriptor) { return descriptor };
var long_deco = function(params) {
    return function(target, name, descriptor) { return descriptor };
};

/*::`*/ @deco /*::`;*/
class Foo {
    /*::_(){`*/ @deco /*::`;}*/
    bar() {
    }

    /*::_(){`*/ @long_deco(
        "params" // ...
    ) /*::`;}*/
    baz() {
    }
}

I don't know that this is a safe thing to do.

[nrako]

:fearful: oh my gosh, that is definitely not a viable solution.

[majhork]

It isn't pleasant but it should be easy to find/replace when they support decorators later and it works right now. Alternatively they could support an ignore construct, like the one I'm kludging, directly in Flow. For example /*:*/ is currently meaningless. It could precede a single-line Flow-only comment, like this:

/*:*/ @deco

Also /*::*/ is currently meaningless and could enclose a multi-line Flow-only comment, like this:

/*::*/
@long_deco(
   "params" //...
)
/*::*/

There could be another form of the above to match /*flow-include*/, like this:

/*flow-ignore*/
@long_deco(
   "params" //...
)
/*flow-ignore*/

This is becoming an increasing pain point as JS standardization accelerates. A general escape hatch would be extremely useful.

[nrako]

I agree that is an increasing pain point which at the moment hold me back from using Flow.

But for the sake of DX, I would rather see decorator ignored by the Flow parser than adding more flow comments...

Anyway, in the long term that doesn't solve the problems, however what is discussed in #454 might. I just hope we'll start to see a clear implementation details of that.

[nmn]

I think for Flow's sake, it should get out of the business of implementing ES6 features entirely and offload that task to Babel.

This would mean that flow should switch to the AST that Babel generates, and do it's thing on that. Babel is already way ahead implementing new ES6 features. It would be a considerable amount of work in the short term, but would free up time for more important stuff in the future.

I'm not sure how difficult it will be to integrate the JS-based Babel into the OCaml based Flow.

[Macil]

@nmn ES6 is set in stone at this point iirc, so there's no longer an issue of Flow chasing a moving target. (And Babel is pretty far along in ES6 support.) A lot of ES6 features would be pretty complicated to support correctly if Flow only operated on the transpiled source. Babel renames scoped let/const variables when there are conflicts, and classes come out pretty mangled. Flow could be made to recognize the specific way that classes get transpiled, but then it probably would fail to recognize the way that classes with decorators get mangled unless it was changed to specifically recognize that. But then if there needs to be code added to Flow to recognize decorators, it might as well be made to just recognize (or ignore) the decorators directly.

That strategy of using Babel might make more sense with experimental/ES7+ stuff. Just use it to transpile things to ES6. Though I don't think decorators on classes can be transpiled to ES6 classes. The proposed :: bind operator is the one thing that I think could be a good workable use of Babel.

[nmn]

@AgentME I'm actually not suggesting that Flow operate on the transpiled version. Babel works in three high level stages:
Parsing, Transformation, Code Generation.

The first Step of the three Parsing is the step where the source code is converted into an AST.

Flow has it's own Parser that does the same thing but to an AST which is of a slightly different format. All I'm suggesting is that Flow should adopt the Babel Parser and focus on error checking.

There would still be some considerable amount of work. Let/Const parsing has been in master for a while, but correctly checking for errors with them is more complicated. So this wouldn't solve the problem completely, but it would reduce the amount of work needed to be done in Flow itself.

Further, with Sebastian now joining Facebook, and React moving to Babel, Babel is much more likely to be contributed to by people other Sebastian as well. Further, Facebook now has some sort of control over the project. So it only makes sense to remove the duplicated effort.

Sebastian has also shown interest in working with Flow to build a better linter. Having a common AST format will definitely help with that.

[gajus]

Flow has it's own Parser that does the same thing but to an AST which is of a slightly different format. All I'm suggesting is that Flow should adopt the Babel Parser and focus on error checking.

Please do that. Implementing Flow in ES6 project is hard. Implementing Flow in a project that is using experiment features is near impossible.

[gajus]

@nmn Please open a separate issue detailing your proposal.

[thomas-jeepe]

Any progress?

[TiddoLangerak]

Using the babel AST would also open up the possibility for pluggable parsers: the guys behind many popular JavaScript parsers, including Babel, have created a spec for a JavaScript AST called estree. If Flow would also use that format then it would automatically be compatible with many of those parsers.

[idolize]

See https://github.com/facebook/flow/issues/850#issuecomment-142730653 for more information on suppressing decorator error output

[thomas-jeepe]

Thanks :)

[STRML]

Just to update the progress of this, decorators are ignorable on methods, not on classes. #1001 is tracking a failing test.

You still must use the above workaround in the meantime.

[marudor]

PR for this:
https://github.com/facebook/flow/pull/1638

[cheapsteak]

It looks like the commits from @marudor 's PR were merged ?
https://github.com/facebook/flow/commit/07ff61c3c4545280d208af3d4c59e89f125b2c65

[LegNeato]

I can confirm that setting esproposal.decorators=ignore in the [options] section of .flowconfig silences the error in latest homebrew release (0.23.1).

[STRML]

:+1: I also see it working (finally get to remove those comment hacks, thanks @marudor!), but perhaps the docs should clarify that class decorators are simply ignored, not typed.

Perhaps we should open another issue to track the work to transition from ignore to enable?

[jeffmo]

Closing thanks to @marudor's fix. Woo!

[c58]

Hey guys! Is there any chance to add a support (just ignore for now) for function decorators in POJOs?
Flowtype generates a lot of errors for this code, even with esproposal.decorators=ignore:

const Test = {
   @test
   func() {
   }
}

It is in decorators proposal https://github.com/wycats/javascript-decorators#object-literal-method-declaration
and supported by legacy babel transformer.

[anback]

This worked for me

[qaiser110]

In .flowconfig set this option:

[options]
esproposal.decorators=ignore

Ref: Flow Docs

[c58]

It works for classes, but not for object properties.

[azarus]

@majhork
/*::*/ @deco /*::;*/

I can't believe that you were thinking its better than the warnin lol

[JanPeter]

Is there any chance that flow will start to support at least class and property decorators if they are in stage-3?

[azarus]

Is there any chance that flow will start to support at least class and property decorators if they are in stage-3?

I think that you can use thirdparty transforms, and add options to ignore the warnings for now?

[c58]

yes, that works, but as i said multiple times before, flow just failing even if ignoring enabled for cases when decorator used with object property like this:

const myObject = {
   @my_decorator
   testFunction(){
   }
}

[azarus]

Well i just looked into flow i wanted to add typings to my library to avoid comon errors with parameter types and the issues were just to overwhelming. SO i ended up using typescript and i wrote a couple of post events that transform the code for my needs. Looking forward to use flow with babel once theres proper support for decorators and for real this thing gets into an usable state.

[JanPeter]

@c58 I've currently the same problem. It seems that if I add decorators to my library I can't get autocomplete to work properly if I include it in a new project via a dependency on VS Code or Atom. Though autocomplete works just fine when I write my tests for the library itself. Maybe somebody could have a look at it. https://github.com/JanPeter/neo4js

[jedwards1211]

@mroch can't ignoring decorators cause type issues? For instance, won't flow complain about a missing foo property in <MyComp /> below, whereas if using connect(...)(MyComp) it wouldn't complain because the react-redux type defs teach it that foo isn't required on the decorated component?

type Props = {foo: string}

@connect(state => ({foo: state.foo}))
class MyComp extends React.Component<void, Props, void> {
  ...
}

const elem = <MyComp /> // won't flow flag an error about a missing `foo` property here?