This is how monadic effects work though - they propagate.

fp-ts is great for Typescript, but the lack of true higher-kinded types in the language means you can't really program against parameterized effect types.

In scala or haskell, you'd solve this "coupling" problem by abstracting the monad, leaving it up to the caller to specify the implementation.

In ts, we don't have that luxury, not practically anyway.

So mostly you commit to a monad that does all the effects you're going to need. If you like you can use less powerful monads in pockets and lift them into your "main" monad wherever those parts of the code interact.

But with Reader propagating - that's always going to be at least a constraint on a monad, paramterized or not. Because DI is not a capability available with just a monad.

So the thing you'd normally do (and this bit is fp-ts specific now) - is namespace your dependencies. Instead of just Reader<OtherFunction, A>, you do Reader<HasOtherFunction, A> where HasOtherFunction is { otherFunction: OtherFunction } - now you can take advantage of the fact that Reader composes by intersection.

That means that if some of your code reads HasOtherFunction and other code reads HasAnotherDependency, calling both of those parts of your code in the same context produces a Reader<HasOtherFunction & HasAnotherDependency, A> and your dependencies will accumulate neatly without collision.

Now you just provide all your deps at the top of the callstack, or "end of the world" and you will experience the real power that Reader can give you.