fix(libp2p): Export Components type for use in apps that use libp2p

[MichaelJCole]

Title

fix(libp2p): Export Components type for use in apps that use libp2p

Description

See #2452

Notes & open questions

See #2452

Change checklist

• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if necessary (this includes comments as well)
• I have added tests that prove my fix is effective or that my feature works

[achingbrain]

Thanks for opening this.

I'm hesitant to export this interface because it encourages the sort of code where everything depends on everything else. This is why the components field is not part of the libp2p interface and is only used internally within the libp2p module.

Could you speak a bit more to your use-case please?

[MichaelJCole]

Hi, I wrote a bit about this in #2449 (comment).

I wrote a bit about the use case in #2454

More or less, my use case is an electron app with a configuration similar to Vuze, utorrent, and other peer-to-peer desktop applications. Those applications set expectations for how configurable they should be. Also, I need to help users around NATs and firewalls and etc. Having access to the addressManager is part of it.

I mentioned in the PR, how Typescript only enforces these limitations at compile time. And they can be trivially overridden:

    // @ts-ignore missing components in libp2p types
    const am = libp2p.components.addressManager as DefaultAddressManager

So not including these types is really just making it harder to use. Javascript runtimes don't enforce private members unless you're compiling to ES2021+ and use # at the start of the names. The _name convention is well understood. IMHO, separating the interfaces from classes and putting them into their own package really just makes things harder for everyone.

Here are some screenshots of the UI's

https://vpn.ac/images/tutorials/socks5/qbittorrent1.png
https://www.bolehvpn.net/images/utorrent1.jpg
https://imgur.com/MQ4zkcA - 10 years old