[Spacetime] Substitute type level error management in favor over try / catch control flow

[DRAFT]

Summary

I dislike how try / catch is used for control flow logic, especially as JS / TS natively do not tell you at the type level, that this is the case: E.g.:

As you can see, QuokkaJS knows at runtime this thunk is throwing, but as you can see in the pop-over, the type system only recongizes a thunk that returns void

Even after I've annotated it, the type system still is unaware of the exception

FP-TS is widely used in our code base, including IO-TS.

io-ts is imported over 100 times in 100+ files right now.
Note: fp-ts is a peer dependency for io-ts FP-TS is being swallowed by EffectTS, but at least we've something that can help us.

Proposal

Build on top of what we have (TS + FP-TS), with future hopes of swapping in Effect in the future, maybe.

There are examples all over the code base, but many are embedded with business logic which makes it more difficult to re-use.

I built something before I came to elastic, that I actually use here, in the code coverage ingestion pipeline. I added this to our repo, before someone added FP-TS as a dependency.

Now, that I've seen more and more use of FP-TS, I think it's time to use it more.

My naive implementation, FP-TS and now Effect all use the same concept: lift values and even behaviours (functions) into a container (box) and then run computations on the value, via the container (box), and maybe even expose the innards especially when the box needs to interact with vanilla js.

Goals

Better tree shaking when classes are not used due to the prototype of every instance of that class, are hanging on to all the symbols. Imagine a class with 100 methods and its referenced in the code like new SomeClass(). You get jungle, a tree and maybe a gorilla, when all you wanted was a banana. Or in our case, a behaviour (function)or some constant value.
Return types that don't lie (as in not mentioning they throw)
Not having to track changes to variables that are visibly out of scope, and are changing...aka Immutability
Not re-invent the wheel on common shapes, like how we all know what [].map or even anything.map()
Not re-invent the wheel on how to control flow, unless we really need to

elastic / kibana