Skip to content
This repository has been archived by the owner on Mar 10, 2020. It is now read-only.

fix: do not assume certain implementations of ipfs are present #584

Merged
merged 5 commits into from
Jan 31, 2020

Conversation

achingbrain
Copy link
Collaborator

@achingbrain achingbrain commented Jan 29, 2020

Passing type: 'js' requires the containing project to have a dependency on js-IPFS which may not be the case.

I don't think anything in these tests requires the js implementation. Please do shout if something does.

Passing `type: 'js'` requires the containing project to have a
dependency on js-IPFS which may not be the case.
@achingbrain achingbrain changed the title fix: do not assume js-ipfs is present fix: do not assume certain implementations of ipfs are present Jan 30, 2020
@alanshaw
Copy link
Contributor

alanshaw commented Jan 30, 2020

refs https://github.com/ipfs/interface-js-ipfs-core/issues/582#issuecomment-580215033

For type: 'go' it's a problem with browser nodes not having swarm addresses to connect to. This PR needs a corresponding PR to js-ipfs to ensure that browser nodes get swarm addrs (by including webtrc transport or otherwise).

ipfs-http-client tests might need to start a webrtc signalling
server in the background.
@achingbrain
Copy link
Collaborator Author

This PR needs a corresponding PR to js-ipfs to ensure that browser nodes get swarm addrs

I've added this to ipfs/js-ipfs#2729 in ipfs/js-ipfs@2b6f0e9

@achingbrain achingbrain merged commit 3d24911 into master Jan 31, 2020
@achingbrain achingbrain deleted the do-not-assume-js-ipfs branch January 31, 2020 12:13
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants