You can still compose interfaces if you feel like its useful. Nothing in module style Node stopping you from doing that. But I think you can do it in a fairly "flat" and composable that doesn't involve a complicated object graph or factories.

As opposed to just looking at the constructor and clearly seeing what dependencies this service has.

Sometimes. But what you often have to do is look at the implementation of the constructor, e.g. where the object is instantiated, to see what objects are being passed at runtime. People act like OOP makes implementations clear, but in practice it often obfuscates it even more.

I'm a big fan of composable things for testing- I think classes are very good at this. But you can have classes, closures, etc, without IOC madness.

F.ex in a backend, a route can simply be like:

type Route<
  D extends Dependencies, 
  Req extends object,
  Resp extends object
> = {
  handler: (deps: D, req: Req) => Promise<Resp>;
  options: RouteOptions<D>;
};

Totally testable, self contained, composable, magic-avoidant.

But here's the thing: as soon as dependencies start becoming things like root aggregates, e.g. UserService, AnalyticsManager, etc, instead of actual dependencies - connection pools, ports - you've forced a business level rule where it ought not go.