Flow: Introduce a way to ignore error

[tychotatitscheff]

Context

Im using a lot of ES7 features since it really simplify and clarify the programm.
For example:

• ES7 decorator (for radium for instance)
• ES7 Property Initializers and binding

I perfectly understand that supporting ES7 is not a priority however their is no way (well the /*:: */` pattern seems not a valid way) to ignore error.

What ESLint does

Eslint provides:

• /* eslint-disable (?P<error-name>)? */
• // eslint-disable-line (?P<error-name>)?

Issue

Do you see such a feature could be done ??
Is it hard (i can help if it is doable by someone that never master caml but sometimes write haskell) ?

[mroch]

You can suppress an error on the following line, much like eslint-disable-line, by setting up a suppress_comment pattern in your .flowconfig's [options] section.

It was previously undocumented... I just added something to http://flowtype.org/docs/advanced-configuration.html

Please reopen if this doesn't work for you!

[STRML]

suppress_comment isn't enough to mask outright parser errors, which ES2015+ features create.

For example:

// $FlowBug: Flow doesn't understand comprehensions
let combinations: Array<string> = [for (a of as) for (b of bs) a + ':' + b];

Throws:

 76:   let combinations: Array<string> = [for (a of as) for (b of bs) a + ':' + b];
                                          ^^^ Unexpected token for

The only way to fix it is to both use the suppression and this really ugly syntax:

// $FlowBug: Flow doesn't understand comprehensions
let combinations: Array<string> = /*::`*/[for (a of as) for (b of bs) a + ':' + b];/*::`;*/

[willclarktech]

+1: I'm getting errors for ES7 bind operators that can't be suppressed with suppress_comment.

[romulof]

ES7 proposal for export ns from can't be suppressed too.

https://github.com/leebyron/ecmascript-export-ns-from

[anilanar]

I have an ES6 class using symbols as properties and this whole class is a mess for flow because flow doesn't support computed property keys. I would prefer to have one of the following:

• ignore certain errors in flowconfig (similar to eslint), so that I can ignore all computed property key errors.
• ignore big blocks of codes (similar to eslint) so that I can wrap my whole class inside it.

Putting suppress comment before every line with a computed property is obviously not the best solution here.

[jamiebuilds]

It would be highly unusual for a parser to support an arbitrary ignore feature for parse errors. How would the parser know when to pick up again? How would it match syntax that exists inside and outside a parse error?

Having an ignore parse errors feature isn't viable. We'll continue work to support the latest ecmascript features as they progress in the proposal process.

[anilanar]

I have no idea how flow architecture looks like and how viable it is from that perspective. However theoretically, flow can handle such use cases similar to what happens when one imports a file/package that is not type-checked by flow; i.e. assign any to everything defined in the block.

One work around for my use case above is to put everything that I don't want to be flow-checked into a separate file, omit // @flow and import everything from it.

For example:

// @flow-disable
const obj = {
  [value]: null
};

class X {
  prop: number

  [value]() {
    return null;
  }
}
// @flow-enable

// At this point the following assertions would hold true
// typeof obj === any
// typeof X === any or Class<any>

[jamiebuilds]

Ignoring ranges makes more sense in a system like ESLint where errors are much more tied to the syntax. To be honest I have no idea how hard it would be to support the same in Flow, but I suspect it would be very difficult because the type system flows through all of the code within it and reaches outside of the syntax itself.

[jtlapp]

Another use of suppress_comment is to allow code to access unofficial internals that are not defined in type definition files and probably shouldn't be. In my case, I'm accessing the connection and requestTimeUTC properties of the Express request object to get the supplied IP and time.

[JeffBaumgardt]

Is there any feedback on if we can get comment blocks such as above where we can tell flow to ignore blocks. I am using jspm and clow is catching on all the require blocks because how the loaders work.

[shamas]

There is a default // $FlowFixMe defined to suppress the next line
https://flow.org/en/docs/config/options/#toc-suppress-comment-regex

[jony89]

what about multiple lines?

[wpcarro]

Is there any answer for suppressing Flow across multiple lines or a block of code?

[mrkev]

Not that I'm aware of, and I'll imagine it won't happen for 2 reasons:

1. This can already be achieved by casting to any. @anilanar's example could be written like this, for example:

const obj: any = {
  value: null
};

class _X {
  prop: number

  value() {
    return null;
  }
}

const X: any = _X

1. It'd be a big change, since the proposed solution would semantically refer to lines, not the language's scopes, and it is entirely possible these don't fit nicely together (ie. the block covers the function header, but ends halfway though the block)

2. Cheating out the type system should be ugly or involve some effort in order to discourage it.

[dominicfraser]

For suppressing flow strict rules across multiple lines it is possible to use:

// flowlint nonstrict-import:off
import firstNonStrictThing from '../xxx/one';
import secondNonStrictThing from '.../xxx/two';
// flowlint nonstrict-import:error

https://flow.org/en/docs/linting/flowlint-comments/

I can't currently see how to do this for a non-strict rule, how to know its name to turn it off?