datastore-idb: Typings broken on helia

[pcfreak30]

on datastore-idb v2.1.2, the typings when passed to createHelia seem to be broken. Oddly blockstore-idb is fine.

error TS2769: No overload matches this call.
  Overload 1 of 2, '(init: HeliaInit<Libp2p<ServiceMap>>): Promise<Helia<Libp2p<ServiceMap>>>', gave the following error.
    Type 'IDBDatastore' is missing the following properties from type 'Datastore<{}, {}, {}, {}, {}, {}, {}, {}, {}, {}>': putMany, getMany, deleteMany
  Overload 2 of 2, '(init?: HeliaInit<Libp2p<{ dht: DualKadDHT; pubsub: PubSub<PubSubEvents>; }>> | undefined): Promise<Helia<Libp2p<{ dht: DualKadDHT; pubsub: PubSub<...>; }>>>', gave the following error.
    Type 'IDBDatastore' is not assignable to type 'Datastore<{}, {}, {}, {}, {}, {}, {}, {}, {}, {}>'.

[welcome]

Thank you for submitting your first issue to this repository! A maintainer will be here shortly to triage and review.
In the meantime, please double-check that you have provided all the necessary information to make this process easy! Any information that can help save additional round trips is useful! We currently aim to give initial feedback within two business days. If this does not happen, feel free to leave a comment.
Please keep an eye on how this issue will be labeled, as labels give an overview of priorities, assignments and additional actions requested by the maintainers:

• "Priority" labels will show how urgent this is for the team.
• "Status" labels will show if this is ready to be worked on, blocked, or in progress.
• "Need" labels will indicate if additional input or analysis is required.

Finally, remember to use https://discuss.ipfs.io if you just need general support.

[tuler]

I'm still unable to use IDBDatastore with Helia because of this issue.
helia@4.0.1 and datastore-idb@2.1.8 are incompatible.

Actually even latest version of MemoryDatastore is incompatible with latest helia.

[achingbrain]

I can't replicate this - can you please share your tsconfig.json and relevant deps from package.json or a minimal reproduction somewhere?

[pcfreak30]

I can't replicate this - can you please share your tsconfig.json and relevant deps from package.json or a minimal reproduction somewhere?

Unfortunately, I have moved on to other priorities in my project, given this was ~8 months ago, and won't be coming back to this for a while.

[achingbrain]

Fair enough, perhaps @tuler can share something

[2color]

I just tried "datastore-idb": "2.1.8" with @helia/http@1.0.1 and had no problems.

See https://github.com/2color/ipfs-signer/blob/067ba9c12ba14005637a284dfb1b99dc39b8d865/src/context/helia.tsx#L25-L33 and https://github.com/2color/ipfs-signer/blob/main/package-lock.json

[tuler]

Thanks for testing it out!
It's some kind of dependency hoisting problem. My monorepo has lots of dependencies, so I'm still trying to figure out who to blame.

For some reason I have both directories below:

node_modules/interface-datastore (8.2.10)
node_modules/datastore-idb/node_modules/interface-datastore (8.2.11)

Here is the full error:

No overload matches this call.
  Overload 1 of 2, '(init: HeliaInit<Libp2p<ServiceMap>>): Promise<HeliaLibp2p<Libp2p<ServiceMap>>>', gave the following error.
    Type 'IDBDatastore' is not assignable to type 'Datastore<{}, {}, {}, {}, {}, {}, {}, {}, {}, {}>'.
      The types of 'batch().put' are incompatible between these types.
        Type '(key: import("/(...)/node_modules/datastore-idb/node_modules/interface-datastore/dist/src/key").Key, value: Uint8Array) => void' is not assignable to type '(key: import("/(...)/node_modules/interface-datastore/dist/src/key").Key, value: Uint8Array) => void'.
          Types of parameters 'key' and 'key' are incompatible.
            Type 'import("/(...)/node_modules/interface-datastore/dist/src/key").Key' is not assignable to type 'import("/(...)/node_modules/datastore-idb/node_modules/interface-datastore/dist/src/key").Key'.
              Types have separate declarations of a private property '_buf'.
  Overload 2 of 2, '(init?: HeliaInit<Libp2p<DefaultLibp2pServices>> | undefined): Promise<HeliaLibp2p<Libp2p<DefaultLibp2pServices>>>', gave the following error.
    Type 'IDBDatastore' is not assignable to type 'Datastore<{}, {}, {}, {}, {}, {}, {}, {}, {}, {}>'.ts(2769)
index.d.ts(66, 5): The expected type comes from property 'datastore' which is declared here on type 'HeliaInit<Libp2p<ServiceMap>>'
(property) HeliaInit<T extends Libp2p<ServiceMap> = Libp2p<ServiceMap>>.datastore?: Datastore<{}, {}, {}, {}, {}, {}, {}, {}, {}, {}> | undefined
The datastore is where data is stored

I'll continue to investigate.

[achingbrain]

You definitely want to ensure you only have one version of a given dep in your monorepo.

Sometimes you'll get lucky and the type overlap will be sufficient for TypeScript to give you a thumbs up, but most of the time it isn't and you'll get errors similar to the ones you are seeing.

You can do npm ls interface-datastore to see which modules have dependencies that clash, but given you have 8.2.10 and 8.2.11 duplicated in your node_modules folder, the first thing I would do is remove any lockfiles you have, then reinstall and see if the problem is resolved, since these are semver-compatible versions.

I'm going to close this issue since neither @2color or myself can replicate, @pcfreak30 isn't facing this problem any more and it sounds @tuler has figured out why they are having issues.

[tuler]

I spent the day trying to figure it out why it was clashing even with a semver compatible version (8.2.10 and 8.2.11). I gave up and forced a resolution to 8.2.11 in the workspace configuration.

I think the issue comes from another monorepo package that uses kubo-rpc-client, and that depends on version 7.0

[SgtPooki]

@tuler we have a lot of updating to do with kubo-rpc-client. I'll be migrating that one to typescript soon and hopefully resolve many outdated dep issues, but currently focused on @helia/verified-fetch, helia-service-worker-gateway and helia-http-gateway for the EthDenver event.

if you do find something specific in kubo-rpc-client that can be fixed, I'd be happy to jump on that sooner than the whole typescript migration if possible.