fix: allow services to indicate their dependencies

[achingbrain]

Some services depend on others, for example circuit relay v2 and kad-dht don't really work without identify so we need a way to prompt the user to configure these dependencies.

The change is to allow extending the components a service requires with a service map of the dependencies.

The components type in the Libp2pInit type is extended by the ServiceMap generic type so when the user configures a node without the required dependencies, TypeScript will fail to compile as the components being passed to the factory function don't have type overlap with the required components.

[achingbrain]

I am not sure why TypeScript can't infer this, it seems to work elsewhere.

[joeltg]

Super cool!

This does feel like it gets close to the line where TypeScript stops being fun anymore... once you start playing the generics game it's hard to stop. Personally I love going crazy with types but it can start to slow people down; it's up to you to weigh those tradeoffs.

Just a thought: if the idea is that "we have some components that get passed around, which always include certain built-in components, ", then would changing everything to take a Components extends BuiltInComponents parameter make more sense than passing around the "service map" just to pass it back into Components<ServiceMap> = BuiltInComponents & ServiceMap? Might be a lot of refactoring but it could eliminate the extra "service map" type concept.

Edit: I guess the other question hanging over this is that the services refactor kinda suggests that people can name their services anything they want now, but in reality dependent services still rely on specific names. Maybe make sure this is communicated in the docs somewhere?

[maschad]

then would changing everything to take a Components extends BuiltInComponents parameter make more sense than passing around the "service map" just to pass it back into Components = BuiltInComponents & ServiceMap? Might be a lot of refactoring but it could eliminate the extra "service map" type concept.

That's a good point @joeltg , the original impetus to even have these optional services was to reduce Libp2p surface area in consumers and also to improve extendability through custom modules. I think at the time we went with the ServiceMap because we were unsure how could have an interface that could facilitate them being accessed from a services key.

I think having the DefaultComponents extend the BuiltInComponents and also having that configuration validated would solve this issue without a large refactor.

Edit: I guess the other question hanging over this is that the services refactor kinda suggests that people can name their services anything they want now, but in reality dependent services still rely on specific names. Maybe make sure this is communicated in the docs somewhere?

Whilst we do now support custom modules I agree the docs should reflect those constraints, perhaps we could have a section in the configuration doc where we indicate that some services require others e.g. setup with relay requires identify ? I opened an issue for further discussion.

[achingbrain]

Discussion: #2135

[achingbrain]

I'm going to close this in favour of the solution proposed in #2135