Relay: [Modern] Export Flow types from `relay-runtime`

[rhysforyou]

As things stand, the Flow types that the Relay compiler generates are unusable without a decent amount of fiddling to stub out the types they import, as documented in #1689.

The gist of it is that these generated files are trying to import various types from relay-runtime, but these types are not exported from those NPM packages. There are various ways to work around this, with the commonly accepted solution being to stub out the required types in a library definition, but these are far from ideal.

In my opinion, the ideal solution would be to include the Flow type definitions in the compiled NPM package. There's a few ways to go about this, from including the original sources alongside the Babel transpiled ones with the .js.flow extension, to including just the types in this with the still-experimental flow gen-flow-files command, but whatever the approach, including type definitions would be tremendously helpful.

[wincent]

Including additional files alongside with .js.flow extensions has worked pretty well on our other GraphQL open source projects.

[leebyron]

I'd love to see this as well. Unfortunately right now it's a bit of a challenge due to the haste transform we need to apply and the fact that our flow types cross reference across our modules, so this would be a non trivial project to take on.

[ekosz]

Could Relay use the transform flow comments babel plugin to make the flow typings into comments and then release that? That way if one is using flow the typing will be picked up. Otherwise normal JS will just skip it.

It seems this is what James Kyle recommends: https://twitter.com/thejameskyle/status/864649054461886464

[rhysforyou]

I assume the upcoming 'blessed' solution is to use flow-gen-files to create .flow.js files that live alongside the library code, but that's currently not fully baked. I totally understand that it's a nontrivial project though.

[leebyron]

Perhaps so, but still requires first addressing the issues I mentioned in the previous comment.

[leebyron]

A temporary workaround may be to use [libs] in your .flowconfig to provide a very simple flow library which supplies only those types which the generated files are importing.

[wincent]

That's the workaround I applied for my blog:

declare module 'relay-runtime' {
  declare type ConcreteFragment = any;
  declare type ConcreteBatch = any;
}

Without this, we can't really list the Flow types as a feature because they are, unfortunately, useless, and fail in the worst possible way (ie. Flow treats them silently as any, leading to a false sense of confidence). That is probably a Flow bug IMO (there are some long running threads on the Flow issues tracker on the subject of failing loudly on importing types which don't exist; this case is slightly different, which is that the presence in the file of another type that Flow can't import prevents the other explicitly exported types from working at all).

[rosskevin]

Here's a temporary libdef for relay modern:
https://gist.github.com/rosskevin/3025518628b16f80c11a2b7385f56169

[sibelius]

@rosskevin can you send this in a Pr to Flow-typed?

[rosskevin]

@sibelius there would be quite a bit of work to do to validate my gist and provide some tests for it. I am not yet 100% converted to modern yet so I'm not comfortable saying it works. My gist is simply a collection of copy/paste so I'm not confident in it yet. I'll update it as I find issues, and may submit it if we have no other options. Aside from that, anyone else is welcome to take that gist and form a PR for flow-typed if the would like.

[rosskevin]

I updated my libdef gist for 1.2, but again, this is just a copy and paste and only in a _works for me_ state.

https://gist.github.com/rosskevin/3025518628b16f80c11a2b7385f56169

I really hope the relay team considers exporting flow types a priority. Keeping up this external gist is a losing battle.

[mike-marcacci]

@leebyron when you talk about cross-referencing modules, are there any that exist outside of this repo, or are you just referring to those built from the source contained here?

[dmnd]

@kassens, I noticed you've been de-hastifying things recently. Based on @leebyron's comment, that should help with this issue. Great!

Do you plan to solve this issue, or is the scope of your current work smaller than that?

[zth]

Sorry to ping in this thread again, but @kassens you recently made a commit that removed the last usage of Haste, right? Does that mean that including the Flow types in the published package is now doable?

[Stephen2]

I've got the great man @kassens on record here saying they should figure it out:

:grin: :laughing:

Let's hope it can be done at some point

[dpeek]

Is this something that an external contributor could help with? Perhaps someone on the core team could create a todo list of intermediate steps? Would love to help out as I'm a Flow junkie, but not sure what the desired approach is.

[iamvasim786]

hi

[zhn1010]

aaeasds

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.