Flow: "Missing type annotation" on exported function parameters is stopping adoption of flow on projects. Can it be turned off?

[tjmkruger]

I have read through some of the issues around this, perticularly this one: https://github.com/facebook/flow/issues/2667

My scenario is that I am inheriting a particularly large code base that exports a lot of functions. I would like to start using flow on the project but cannot justify changing every function that is exported. I need to be able to annotate the function that deals with the problem I am facing and move on. It is a perfectly reasonable style for a codebase but I cannot justify rewriting large chunks of code for tooling sake.

As I understand from @jeffmo in the issue above this is done for performance. I think its perfectly reasonably this being the default but would like to see an option to turn it off even if means taking the performance hit.

Can it be turned off, perhaps with an option?
It would improve the ability to adopt Flow on existing projects.

export default function foo(x): string {
  return "default string";
}

try it

[apsavin]

What’s your .flowconfig?

[tjmkruger]

At the moment pretty simple:

[ignore]
.*/node_modules/.*

[lints]
all=warn

[phpnode]

export default function foo(x: *): string {
  return "default string";
}

[tjmkruger]

Hi @phpnode, that does work but still requires me to spend a lot of time updating the code in my project. Its not so much about the syntax but about using Flow on an existing larger project that already exports functions without annotations. I can't justify spending developer time to add annotations for tooling. I would like a way to add the annotations over time as I change the code over time while still delivering new features to the app.

[apsavin]

With the config like above flow asks for types only in files with @flow pragma, isn't it?

[bsmith-cycorp]

+1 to this. Given how much Flow's marketing talks about implicit type inference, it should be possible to apply it to your whole codebase without any type annotations and get some amount of benefit. Opt-in using @flow is better than nothing, but it means Flow has to ignore all code you haven't yet gotten to in your refactor (or intentionally don't want to be explicit about), which for larger codebases can be a whole lot, and for an extended period of time. At the very least there should be a config option to disable "Missing type annotation"-style errors.

In the past two weeks of trying to graft Flow onto an existing React codebase, it's created a whole lot more noise than signal, which is quite discouraging and has me questioning the decision to use it at all. Strictness issues like this are a big part of the problem.