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

Hi HN,

I built fp-pack, a small TypeScript functional utility library focused on pipe-first composition.

The goal is to keep pipelines simple and readable, while still supporting early exits and side effects — without introducing monads like Option or Either.

Most code uses plain pipe/pipeAsync. For the few cases that need early termination, fp-pack provides a SideEffect-based pipeline that short-circuits safely.

I also wrote an “AI agent skills” document to help LLMs generate consistent fp-pack-style code.

Feedback, criticism, or questions are very welcome.

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

How is this not a monad? It might be trying really hard not to reify the core concept of a monad, but it seems to me like it ends up being essentially a complicated monad.

The default any return type from pipelines is kind of brutal. Seems like a real footgun. Is that fixable?

It’s definitely monad-adjacent.

The main difference is that SideEffect isn’t a compositional context — there’s no bind/flatMap, and composition intentionally stops once it appears. It’s meant as an explicit early-exit signal in pipe-first code, not a general computation container.

That’s a fair point — it can definitely become a footgun if you’re not careful.

This happens because `runPipeResult` defaults its generic parameter to `R = any`. When type safety matters, the intended solution is to use `pipeSideEffectStrict`, which preserves all possible SideEffect result types as a precise union throughout the pipeline.

The default version prioritizes ergonomics and simplicity, while the strict version prioritizes type safety.

Also, fp-pack is still in an early stage, so the usability and API choices haven’t been fully validated yet. That’s why feedback like this is especially helpful in shaping the direction of the library.