-
Notifications
You must be signed in to change notification settings - Fork 127
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
js-ipfs dependency updates, now with full types (WIP) #1194
Conversation
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.
Thanks @rvagg! Glad to see the ipfs types working better.
Probably need some integration work between dag-jose and the latest multiformats update and probably needs multiformats/js-multiformats#67 to be done
Right, the dag-jose codec has not been updated in quite a while. It could definitely use an update to more recent packages (multiformats, cids, cbor).
const asCid = typeof cid === 'string' ? new CID(cid) : cid | ||
const record = await this._ipfs.dag.get(asCid, { timeout: IPFS_GET_TIMEOUT }) |
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.
Does the dag api require CID instances 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.
yes, but actually probably shouldn't! ipfs/js-ipfs#3637
packages/core/src/pubsub/pubsub.ts
Outdated
@@ -71,7 +72,7 @@ export class Pubsub extends Observable<PubsubMessage> { | |||
return this.peerId$ | |||
.pipe( | |||
mergeMap(async (peerId) => { | |||
await this.ipfs.pubsub.publish(this.topic, serialize(message)); | |||
await this.ipfs.pubsub.publish(this.topic, uint8ArrayFromString(serialize(message))); |
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 suppose we need to do the invert on incoming messages?
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.
dht: { | ||
enabled: false, | ||
clientMode: !configuration.ipfsDhtServerMode, | ||
randomWalk: false, | ||
}, | ||
pubsub: { | ||
// TODO: @rvagg is this gone? | ||
// @ts-ignore | ||
enabled: configuration.ipfsEnablePubsub, |
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.
Were we doing this wrong or did it change?
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.
@vasco-santos can you answer this one? I can't get to the bottom of the change here. dht
and pubsub
have been lifted out of config
to the top level in the libp2p
config options. Was that always wrong here, or a recent change, or a problem with types?
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.
This is still inside the config, so this should not really be changed. Were there type errors configuring inside the config property?
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.
The in progress branch of js-ipfs
with the types improvements also has it inside the config, so the types should be correct upstream: https://github.com/ipfs/js-ipfs/blob/chore/update-buffer-deps/packages/ipfs-core/src/runtime/libp2p-nodejs.js#L42
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.
See ipfs-core/src/types.d.ts and how it pulls in Libp2pConfig
rather than Libp2pOptions
. I think this is the source of the problem but you'll have to confirm. ipfs/js-ipfs#3640
@@ -52,7 +51,7 @@ export class IpfsTopology { | |||
) {} | |||
|
|||
async forceConnection(): Promise<void> { | |||
const base: string[] = BASE_BOOTSTRAP_LIST[this.ceramicNetwork] || []; | |||
const base: Multiaddr[] = BASE_BOOTSTRAP_LIST[this.ceramicNetwork] || []; |
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.
Is there a change needed to BASE_BOOTSTRAP_LIST
as well?
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.
Probably shouldn't be so restrictive, opened an issue @ ipfs/js-ipfs#3638
@oed I'd like to have a go at updating dag-jose, it'll be good validation of work we've been doing around multiformats and codecs recently, and we want to get the types right (tho the |
@rvagg sounds great! Let us know if you run into any problems along the way. |
packages/core/src/pubsub/pubsub.ts
Outdated
@@ -71,7 +72,7 @@ export class Pubsub extends Observable<PubsubMessage> { | |||
return this.peerId$ | |||
.pipe( | |||
mergeMap(async (peerId) => { | |||
await this.ipfs.pubsub.publish(this.topic, serialize(message)); | |||
await this.ipfs.pubsub.publish(this.topic, uint8ArrayFromString(serialize(message))); |
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.
Guess, this to uint8array convertation should be put into serialise
function @rvagg
Concerned about dag-jose codec (does it work with types enabled?) and typed |
6c8f096
to
dc0859a
Compare
dc0859a
to
4a7476b
Compare
rebased to master and added some minor changes, still a few open questions about the js-ipfs core types |
continued in #1337, because that's a better number, obviously! thanks @achingbrain |
This is against an RC of the ipfs suite of packages which have full typing compiled and exported. Using this to test the RC for now but hopefully this will be a helpful addition when complete!
@achingbrain the things that stand out here are:
JSIPFS
type in ipfs-http-client, defined asIPFS & { ipld: IPLD, libp2p: libp2p }
, is maybe too broad? I'm not sure what to do with this fornew HttpApi()
and I see we even still@ts-ignore
those calls in tests too.IPFS.create()
config{ pubsub: { enabled: boolean } }
did that go away or do we have typing wrong forenabled
?