Breaking change in v0.9.1 about js-libp2p-gossipsub HOT 6 CLOSED

I think this sort of problem can be alleviated by exporting interfaces from .d.ts files and then everything depends on the interface, rather than typing an implementation and using that as argument types, etc. This is the approach taken by Store in ipfs-interfaces.

I will try it next week

N.b. floodsub has a similar problem but IPFS still compiles by coincidence as the default code path finds gossipsub and not floodsub.

Just did the same for it

from js-libp2p-gossipsub.

[email protected] only added tests, I am not sure of what changed. But I can revert the commit and do a breaking change here

from js-libp2p-gossipsub.

I think it's just because the types are loaded from different paths, same as the problem with instanceof and loading classes from different locations.

from js-libp2p-gossipsub.

I reverted with a patch and released a minor. Should be good now?

Bah, we will need to orchestrate really carefully the libp2p-interfaces update in js-libp2p

from js-libp2p-gossipsub.

I think this sort of problem can be alleviated by exporting interfaces from .d.ts files and then everything depends on the interface, rather than typing an implementation and using that as argument types, etc. This is the approach taken by Store in ipfs-interfaces.

This way at compile time TS compares the interfaces to see if there is overlap instead of checking all the fields etc of the implementation, which may be concrete types with complex field hierarchies that are unlikely to be compatible across versions.

from js-libp2p-gossipsub.

N.b. floodsub has a similar problem but IPFS still compiles by coincidence as the default code path finds gossipsub and not floodsub.

Anyway, the patch has fixed it, thanks!

from js-libp2p-gossipsub.