eslint-plugin-expect-type VS sum-types

You can test types, at least in terms of asserting happy path types and whether a piece of code, runtime or purely type-level, should trigger a tsc type error. Here's an example using eslint-plugin-expect-type.

I entirely agree about using symbols. sum-types does that.

With fp-ts and sum-types you'd handle this functionally like so:

If you're looking to have discriminated unions like Rust, follow that section to roll your own or look for a library that's already implemented them. fp-ts has everything under the sun in a Haskell style, neverthrow has Rust-like Result and ResultAsync, and sum-types helps with the boilerplate of defining your own sum types.

I'd suggest sum-types. Instead of unsafe user-defined type guards you get safe pattern matching.

If you wanted to lean (more) into FP you could replace the Event type and buildPopup function with a sum type and pattern match respectively, as well as represent side effects like in popup with fp-ts' IO, make use of function composition, etc. The former in particular is great for readability:

You can test types, at least in terms of asserting happy path types and whether a piece of code, runtime or purely type-level, should trigger a tsc type error. Here's an example using eslint-plugin-expect-type.

Anywhere that overloads are needed will rely upon type assertions or the unsafety implicit in overloads, for example in fp-ts/function::pipe. It'll come up a lot with objects too when there isn't a preexisting primitive you can compose atop of, as in for example fp-ts-std/Record::pick. Something as generic as @unsplash/sum-types has assertions all over the place, though to be fair that's mostly again a case of struggles interacting with object types.

You might like @unsplash/sum-types also.