New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Time to deprecate `gen-flow-files`? #5871

Open
ryami333 opened this Issue Feb 26, 2018 · 11 comments

Comments

Projects
None yet
10 participants
@ryami333
Copy link
Contributor

ryami333 commented Feb 26, 2018

The command gen-flow-files has been around a while now, and it's been almost untouched since it was released as an experimental command in v0.32.0 about a year and a half ago. I'm unaware of any libraries using this in production (probably because for most use-cases it just doesn't work).

I think there are dangers of leaving such a buggy/experimental command in there with no active intent on fixing/updating it:

  • Library maintainers could be waiting indefinitely for an update rather than seeking out alternative means (like flow typed or flow-copy-source)
  • Library maintainers might be publishing buggy lib-defs without realising it.
  • Or worse, they can be frustrated by gen-flow-files so much that they abandon Flow types altogether.

I think the command should be deprecated and ultimately removed, and documentation updated to reflect the official recommended pathway to publishing types, whatever that may be.

@ahem

This comment has been minimized.

Copy link

ahem commented Feb 26, 2018

I consider it a pretty useful tool and I am using it for a bunch of internal modules. It doesn't generate the most readable output, but I also haven't run into any problems with it.

@MarkKahn

This comment has been minimized.

Copy link

MarkKahn commented Mar 4, 2018

I'd personally like to hear the status and long-term plan on this before voting to remove it as the tool has the potential to be very useful. flow-copy-source is at best a patch for what gen-flow-files has the potential to be.

@ryami333

This comment has been minimized.

Copy link
Contributor Author

ryami333 commented Mar 6, 2018

Yeah I agree that it has the potential to be very useful, but at the moment it's essentially just vapourware, or at least it carries all the associated risks of vapourware.

@chixor

This comment has been minimized.

Copy link

chixor commented Mar 8, 2018

I disagree to calling it vapourware because we actively useflow gen-flow-files with satisfying results.

Use case
We have 50+ private flow-typed repositories.

Why we don't use flow-typed
We can't use a public repo for the flow types of private repos. We also can't use one private repo for flow types because among the 50+ repos it would have to represent there are conflicts between repos that wouldn't coexist anywhere else. For this approach to work we'd have to manage multiple private flow type repos, which adds needless overhead for us. We much prefer a single source of truth approach.

Why we don't use flow-copy-source
flow-copy-source merely duplicates the entire source code into the /lib dir. This means doubling the install for 50+ repositories which is ridiculous (not to mention messy) given types make up less than 20% of our source code.

flow gen-flow-files to the rescue!
flow gen-flow-files solves all the above problems for us. We don't need to manage several special flow type repositories or add any extra work to our upgrade process. Nor do we need to double the size of our distributions. By adding this one line to our build script, flow types are released in the repository that defines them (under the correct version numbers and everything) and ONLY the flow types - nothing else. So simple!

If we had to resort to managing multiple flow type repositories to avoid doubling our distributions, THAT might be reason enough to get frustrated and abandon flow types altogether :(

@deepsweet

This comment has been minimized.

Copy link

deepsweet commented Mar 20, 2018

I personally have almost zero examples when gen-flow-files works – it produces everything from bugs to syntax errors, especially with exports. In my opinion it should be either deprecated or much improved, but not left in its current confusing state.

@iddan

This comment has been minimized.

Copy link

iddan commented Mar 22, 2018

I think improvement is very possible and this tool is necessary. I use it (even though it produces bad syntax) for my alpha package reactive-material

@zaynv

This comment has been minimized.

Copy link

zaynv commented Mar 26, 2018

It's a shame because this feature is really important to have :(

Things like styled-components which is written in Flow doesn't even ship with type definitions, and flow-typed is always very behind in adding libdefs for new version of it (v3 still isn't in flow-typed).

Also, the new Pinterest library written in Flow needs to resort to weird hacks like this in order to ship flowtypes.

@TrySound

This comment has been minimized.

Copy link
Collaborator

TrySound commented Mar 26, 2018

@zaynv this is not a hack. It's quite flexible way to provide as much as need entry points without a lot of duplications and ugly configs. Consider it as an official way to provide definitions from source.

Styled-components are probably had an issue I wasn't faced. They could use the same solution.

@zaynv

This comment has been minimized.

Copy link

zaynv commented Mar 26, 2018

Hmm, but even the creator of that Pinterest library referred to it as a hack. It's pretty weird to need to include the entire src directory in order to ship type definitions.

Also, I have a question about using types flow-typed? If you're only including files from src, the types you import from flow-typed definitions won't exist right? Will that make the types break?

@mgrip

This comment has been minimized.

Copy link

mgrip commented Nov 1, 2018

Any more discussion on this? I think this could definitely be a turn-off for people getting heavily invested in flow, especially for people who are active in publishing open-source modules. It seems pretty important for people to be able to easily and efficiently publish code written with flow types so that other projects using that code can get the types if they're also using flow, while still supporting other projects that aren't using flow. Typescript already has a solid solution for this, for comparison (basically the same as gen-flow-files).

@nmote

This comment has been minimized.

Copy link
Contributor

nmote commented Jan 18, 2019

We have some solid building blocks nearly done for a real replacement for this command. We understand that it's important for library authors who are using Flow to be able to publish libdefs.

We don't have an exact timeline, but I believe that this will be available within the next six months.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment