Show HN: FP-pack – Functional pipelines in TypeScript without monads

I really relate to that.

There’s often a gap between what feels conceptually clean and what teams are actually willing to carry cognitively. Rx in particular tends to exceed that budget pretty quickly.

That’s why fp-pack is intentionally narrow — it’s closer to making a few control-flow cases explicit in pipe-first code than introducing a broad new abstraction.

I understand the concern.

The intent isn’t to add more side effects to an already side-effectful language. It’s closer to the opposite: trying not to handle side effects all over the place, but to surface them as part of a single, explicit flow.

This is less about adding something like Option to a language without nulls, and more about making control-flow boundaries visible in a multi-paradigm language where effects already exist.

It’s not an attempt to pretend the language is pure, just a small step toward more declarative discipline.

One more practical point is that a full monad doesn’t fit very naturally into a pipe-first interface.

Once you commit to a real monad, you need map/flatMap, lifting, unwrapping, and rules about staying inside the context across the whole pipeline. At that point, the pipe abstraction stops being the primary mental model — the monad does.

SideEffect deliberately avoids that. It keeps the pipe interface intact and only adds a single, explicit signal: “stop here”. That’s why it’s less powerful than a monad, but also much simpler to integrate into existing pipe-based code.