-
Notifications
You must be signed in to change notification settings - Fork 127
js-ipfs dependency updates, now with full types (WIP) #1194
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
Conversation
oed
left a comment
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
| .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
|
|
||
| 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
| .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:
JSIPFStype 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-ignorethose calls in tests too.IPFS.create()config{ pubsub: { enabled: boolean } }did that go away or do we have typing wrong forenabled?