[Question] what's the future of flow gen-flow-files?

[chixor]

In my team we use flowtypes across multiple packages which are distributed by npm. In order to build those flowtypes into /lib dirs for consumption in other packages we're using the experimental flow cli command flow gen-flow-files.

We prefer this option over the alternatives (eg, flow-copy-source) because it doesn't duplicate our entire source code in /lib, only the relevant flow rules.

gen-flow-files has been 'experimental' for over a year. I wanted to know what the plans are for this feature? Are there any? Is it being actively developed or just maintained? Has an alternative solution been discussed?

I just want to get a sense of what you guys are thinking :)

Ping recent developers @mroch @gabelevi @ballardrog

[Andarist]

@calebmer any comments on this? Publishing typings to npm is somewhat iffy in flowland at the moment, would be good to have officially supported & blessed way of doing it.

[dvakatsiienko]

+1. It is clear that typing should live in flow-typed repository, but it might be not so obvious for everyone

[Andarist]

Even if that is the case, it would be nice to have a guide about this - especially how to efficiently synchronize a library written with flow with flow-typed repository. Having to remember about updating typings each release doesnt seem a good DX

[beckerei]

Private npm packages should not distribute their flow types via a public flow-typed repository. For me it makes a lot more sense to distribute the types with the package.

[chixor]

Our npm packages are also private. Theoretically we could create a private flow-typed repo specifically for distributing flow types but I much prefer this single source of truth approach for each discrete package, it's much easier to maintain. This is why I'm hoping for flow gen-flow-files to be more than just 'experimental'.

[kayneb]

Yeah, we would love to have this be supported functionality too. We have a suite of internal npm modules that we consume across a couple of different projects that use flow - exporting flow types via the npm module is the preferred approach for us.

[steida]

#5871

[SethDavenport]

I have pretty much the exact same use case as @chixor and I'm running into a wall. In our case, we have a bunch of internal packages and I don't want to maintain a ton of build toolchain for each one separately. We internally publish the raw ES6 source in each package and have the top-level consumer decide how to do the bundling, transpilation, etc. Developers work with yarn link.

The issue is that I either include node_modules, and types for our internal packages are picked up, but the cost is that flow becomes unusably slow; or I expose types in a way similar to flow-typed (but internal) but at a cost of a lot of synchronization issues with types and code getting out of date with each other.

I think what I really want is

1. a way to exclude all of node_modules except for a shortlist of my internal packages, and
2. a way to have my package declare its module name and export existing types from the code without duplication. E.g. something like:

index.js.flow

declare 'my_internal_module' {
  // export all the types from .src/index.js without manually duplicating or running a build step.
  // not real syntax...
  export type * from './src/index'
}

For (1) I've tried

[ignore]
.*/node_modules/.*

[include]
<PROJECT_ROOT>/node_modules/my-internal-package

But since [ignore] overrides [include] that doesn't work. If it were the other way round that would be awesome.

I've tried refining my ignore to something like .*/node_modules/(!?my_package)/.* but apparently you're using Ocaml regexes which don't appear to support negative lookahead. So that doesn't work. If the regex support were more standard that would probably solve it.

I've tried

[ignore]
.*/node_modules/.*

[options]
module.name_mapper='^my-internal-package$' -> 'node_modules/my-internal-package/src/index.js'

but this complains that the the module can't be resolved (I guess [ignore] node_modules is once again interfering?). TBH I'm not too sure why this doesn't work.

I've tried

[ignore]
.*/node_modules/.*

[libs]
node_modules/my-internal-package/async-action/src/index.js.flow

but this form seems to expect to find a declare module 'my-internal-module' somewhere.

I was at one point using gen-flow-types but I had to manually edit the output because it wasn't correct; so this won't really scale for me. Since updating to 0.69 it just gets stuck in an infinite loop and doesn't output anything.

It's worth noting that this is one thing that typescript does pretty well; their compiler can generate a .d.ts file automatically from your source code, whereas just importing a TS file doesn't require a module declaration regardless of where it lives.

[SethDavenport]

Hmm looks like I can make my workflow work but only if I remove the all=true option and then add // @flow comments to all the files of all my internal libs. This way I can include all of node_modules without a huge performance penalty, and my top-level app can simply consume flow-enhanced JS source files from the internal modules as if they were any other file, extra declares not needed.

The downside is I have to go and

1. add // @flow to a few hundred files
2. make sure everyone on my team does this consistently (remember use strict;? 😂 )

Still it seems to be the lesser of two evils.

[fibo]

In my opinion the typescript behaviour that reads an index.d.ts file is really comfortable.

What about reading ${npm_package_main}.flow by default, and let flow cache files so it does not need to scan node_modules folder every time (maybe it is already implemented).

From the point of view of a user, flow is really promising, but this kind of conventions should be well defined and documented, and easy, in order to increase the tool adoption.

[SimenB]

@fibo That already works. If you import index.js, it reads types from index.js.flow (if it exists)

[fibo]

@SimenB thanks, I could not spot it in the documentation or some article. I guess that if user ignores node_modules this will still work.

[TrySound]

gen-flow-files is removed. A replacement is coming soon.

[aryzing]

@TrySound how soon?