[Discussion]: Any plans to make Flow more interpopble with TS ecosystem?

[sekoyo]

The problem is that flow doesn't have any tool to convert TS to Flow even though most TS features are now possible. This breaks the formula of upstart success: performance x interoperability = success that we see in projects like Bun(to Node), Go+Rust+Zig(to C).

Right now anyone using flow has to go through the painful process of converting the TS definitions of almost any NPM module they want to use by hand and then maintaining them. I think the fact that flow is written in OCAML which is reasonably fast and portable compared to TS is quite a big win but without easy interoperability with the ecosystem it's a tough sell. Which is a shame as a week of TLC to a project like flowgen to bring it up to date (almost all features it says are missing or has polyfilled are now supported, I added support for most of them in a fork in 1-2 hours but project maintainers are inactive, there are still more e.g. type guards), and add it to CLI e.g. flow convert <npm-package> would make flow a more viable option.

[SamChou19815]

Do you mind if I reopen this issue? I think this is a valuable discussion to have.

This year we have started converging with TS where it makes sense. e.g. we now have conditional types, mapped types and type guards. We are also in the process of changing some syntax to align with TS, such as the casting syntax (prettier/prettier#15130) and some smaller items (prettier/prettier#15429, prettier/prettier#15466). You can follow some progress in #8989.

The next logical step is .d.ts support. This is an umbrella project that contains a lot of smaller items (e.g. declaration merging, namespace, TS syntax, etc). That being said, I cannot promise anything concrete or a timeline here. In the internal prioritization process, OSS is unlikely to make it to the top. However, I am more optimistic this time. We finally finished big architecture changes (types first) and big rewrites (LTI) so that our performance and type checker are no longer on fire, so we can focus more time on DevX issues like this. Lack of interoperability with the TS ecosystem is also an internal developer pain.

I appreciate your passion for Flow even though a lot of things are stacked against us now. I do have a personal passion for this, since I was on your side before. In 2018-2019, I used Flow but eventually gave up due to lack of well-maintained flow-typed definitions. I believe there is something we can do here.

[sekoyo]

Thanks for the great answer. I was regretfully a bit passive aggressive in places cause I was in the middle of converting some d.ts 😅 Actually tbh I just renamed the files and merged them together and there wasn't much work besides that which was cool to see - definitely getting closer.

That's encouraging to hear and the closing feature parity is noticeable, understandable if you're not at the stage to make stable automatic conversion yet/don't have the time. Side note: cool I find the as syntax more visually pleasing anyway ;)

[matclayton]

Sorry to not really bring much to the table with this, but wanted to say this would be an absolute game changer for us as well. Flow is a fantastic tool, we particularly appreciate the integration with relay, but the lack of support for typescript defs really causes us headaches on a weekly basis. I truely believe this is the only major headache we have with it and adding def support would save an enormous amount of time.

[SamChou19815]

We planned next year that we are going to tackle this. More specifically, I will look into the following aspects, in order of priorities:

1. namespaces (only for type definitions)
2. declaration merging
3. some cosmetic syntax changes to directly understand TS definitions

By the end of next year, our goal is not to understand every single .d.ts file without issue, but hopefully as we progress, you will need fewer and fewer manual edits to an upstream d.ts file to make it usable in Flow

[SamChou19815]

Once we make the next release, it will contain d8bba3c, which will make it less hostile to use TS type names.

Note that this is best effort support (e.g. eslint and prettier support might not be ready when we allow more stuff under the flag), but if you actually managed to use other tools only designed for TS but use flow for type checking, we'd like to hear from your experience.

[canadaduane]

Every once in a while I revisit Flow to see how the interop story is moving along, because the awesome type system and tooling around Flow are so encouraging. Are there resources where I can read about progress in the past year? Thanks for all your efforts.

[SamChou19815]

The experimental.ts_syntax flag is the major progress this year. I also implemented some experimental d.ts to .js.flow translator in the flow-api-translator package.