-
Notifications
You must be signed in to change notification settings - Fork 46
Conversation
e012fdd
to
a49b546
Compare
src/index.js
Outdated
@@ -2,7 +2,6 @@ | |||
|
|||
const connect = require('pull-ws/client') | |||
const mafmt = require('mafmt') | |||
const includes = require('lodash.includes') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can this module be removed from the dependencies now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it's gone! 👍
src/index.js
Outdated
return mafmt.WebSockets.matches(ma) || | ||
mafmt.WebSocketsSecure.matches(ma) || | ||
mafmt.WebSocketsIPFS.matches(ma) || | ||
mafmt.WebSocketsSecureIPFS.matches(ma) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following multiformats/js-mafmt#16 (comment), if you do multiple assertions anyways, why having some mix and some not. Just assert for IPFS separately.
From this Boolean assertion, seems that having IPFS is actually not relevant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't sure when I coded this if it was the best way of doing it. The main idea behind leaving the non IPFS version was fear of breaking something else. I think in this case it should be safe to just do:
mafmt.WebSocketsIPFS.matches(ma) ||
mafmt.WebSocketsSecureIPFS.matches(ma)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for being able to just do IPFS.match(ma) as you pointed out in multiformats/js-mafmt#16 (comment), I don't think that would work, since it would also match TCP and WebRTC addrs here.
08ab66b
to
e600990
Compare
e600990
to
58410a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@dryajov a PR should not be considered "Ready to Review and Merge" if CI is failing.
Also, could you make sure to update deps as part of this PR?
Seems like travis is failing on an IO error, not sure what it means exactly - I don't see a specific error besides Also, I don't have a way of triggering rebuilds so my ability to troubleshoot this is limited. |
@dryajov use the latest CI configs from https://github.com/ipfs/js-ipfs |
package.json
Outdated
"coverage-publish": "aegir-coverage publish" | ||
"lint": "aegir lint", | ||
"build": "aegir build", | ||
"test": "aegir test --target node --target browser", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
try with --no-parallel and increasing the timeout for the test with multiple writes
@diasdavid this is passing now in both travis and circle... had to go pretty aggressive with the timeout tho, will need to fine tune - but I think we can merge safely for now? |
@diasdavid I removed the global timeouts and this should be ready to merge. |
* feat: resolve 0 addresses * chore: upgrading pull-ws * chore: update circle CI * chore: update gitignore
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's wait for that CI now :)
This depends on mafmt PR - multiformats/js-mafmt#16