Some of them can worked around by structuring your code in certain ways (for example you could make sure every variant is covered by indexing into an object with `key in MyEnum`, or by returning from each switch case and requiring a particular return type)
But even setting those aside, I got burned so badly the last time I used Flow that I'm not sure anything could convince me to return to it
Because we’re planning on moving our codebase to ESM support (the community is moving over quickly), we’ve run into a number of issues with TS enums, the primary one being that TS enums compile to undefined vars that are populated with an IIFE, which disallows using them in certain import/export situations.
Docs for enums compilation/runtime are here: https://flow.org/en/docs/enums/defining-enums/#toc-enums-at-...
The only downside so far is that `[Example.First, Example.Second].includes(user.example)` no longer works because the array's type is narrowed to the tuple `("first", "second")` instead of an array of Examples `Example[]` without casting: `([Example.First, Example.Second] as Example[]).includes(user.example)` or worse `[Example.First, Example.Second].includes(user.example as any)`. Because this is an extremely common pattern for us, we've taken to using the lodash function `includes` which is typed differently but performs the exact same check under the hood.
