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.
My solution is to make a type guard:
function isExample(val: string): val is Example {
return (ALL as string[]).includes(val)
}
(you don't even need the array unless you need to iterate over the items at runtime like above; in other situations, you can often just make a type and nothing else)