tsd VS sum-types

Nice. Have you checked out tsd? Would you consider your library to be a viable alternative to tsd?

The library we're going to use to execute these static type tests is one that I made called jest-tsd. It's a wrapper around tsd to make it really easy to use with Jest.

But even with a very strict TS/ESLint configuration, you can't avoid a typing error. I looked for libraries to test types and I was very surprised to see that it is not a very common practice and there is not much choice. The most popular one seems to be tsd, unfortunately like all the other libs I found, it does not integrate with existing tools.

How is this different than tsd ? https://github.com/SamVerschueren/tsd

Yep. Similarly I'm surprised there's no built in way to test typescript definitions, so I end up using tsd.

``` import {expectType} from 'tsd';import concat from '.';expectType(concat('foo', 'bar'));expectType(concat(1, 2)); ``` https://github.com/SamVerschueren/tsd

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.