recent npm releases are not backward compatible. Rebuilding package-lock.json breaks my app

pepoospina commented 4 years ago

Version: I'm currently importing "ipfs": "^0.49.1" in my package.json files.
Platform: Running on ubuntu, but the app is being compiled with rollup and runs in the browser.
Subsystem: Not sure.

Severity:

Critical - System crash, application panic. Our app stops working if we recompute the package-lock.json files (which we have to because we are adding other dependencies)

Description:

Simply deleting the package-lock.json files and runing npm i again will break our app. Unfortunately, we don't have simple tests and the app is quite big and heavy.

What I can tell you is that we are using "orbit-db": "^0.24.1" and the error appears when orbit-db wants to publish to an ipfs-log.

Specifically inside the append function of ipfs-log when calling Entry.create(). It then goes to Entry.toMultihash, io.write() and finally ends up calling ipfs.dat.put() with the orbit-db object.

It never returns the cid, and instead throws

TypeError: Cannot read property 'length' of undefined↵

Steps to reproduce the error:

You need to deploy and interact with our app. It's 100% reproducible. If you think it's worth it, I can help you deploy the app.

This commit is the one in which the lock files are rebuilt and fails. https://github.com/uprtcl/js-uprtcl/commit/930659da89a865371aab02253ecbed05fe5afe15

Its parent https://github.com/uprtcl/js-uprtcl/commit/2d50e20cb91edb034e43a126d7b20d44604f6573 works

welcome[bot] commented 4 years ago

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.

pepoospina commented 4 years ago

I upgraded to ipfs 0.50.1 and orbit-db 0.25.1 and the issues is fixed.

achingbrain commented 4 years ago

Could you post a full stack trace of the error please?

pepoospina commented 4 years ago

Really sorry but I can't @achingbrain . I'm using ApolloClient and it hides the error stack and shows only the last one. I'm starting to think about why I decided to use Apollo...

achingbrain commented 4 years ago

I'm going to close this because it sounds like you've resolved your issue by upgrading your deps and you cannot provide any more information to diagnose the problem.

Please reopen if you can supply a reproducible case.

pepoospina commented 4 years ago

Hi @achingbrain , it seems the error is back?. I've seen I'm now using ipfs v0.50.2 (due to my dependency being set as ^0.50.1)

Maybe the latest 0.50.2 release broke something?

I will now test with the latest version of my app with 0.50.1, which I know was working, and recompute the lock files to see if it fails.

I will let you know.

achingbrain commented 4 years ago

0.50.1 was released with a dep on ipfs-http-client 46.1.1 which was mistakenly released with breaking changes - they were reverted for 46.1.2 and re-released under 47.0.0, which 0.50.2 updates to. So there weren't any code changes in there, just the ipfs-http-client dep.

Anyway a similar error to the one you're seeing was reported at https://github.com/orbitdb/orbit-db/issues/839 - the cause was multiple incompatible versions of the cids module in the dep tree, could you please verify you only have a single version in use?

From the root of your project, after an npm install run:

$ npm ls cids

pepoospina commented 4 years ago

Hi @achingbrain , only now I was able to run this.

This is what I see:

imple-editor@0.0.7-alpha.56 /home/pepo/pr/pr/uprtcl/js-uprtcl-secondary/demos/simple-editor
└─┬ ipfs@0.50.2
  ├─┬ cid-tool@1.0.0
  │ └── cids@1.0.0  deduped
  ├── cids@1.0.0 
  ├─┬ dag-cbor-links@2.0.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipfs-bitswap@3.0.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipfs-core-utils@0.4.0
  │ └── cids@1.0.0  deduped
  ├─┬ UNMET PEER DEPENDENCY ipfs-http-client@47.0.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipfs-repo@6.0.3
  │ ├── cids@1.0.0  deduped
  │ └─┬ ipfs-repo-migrations@5.0.5
  │   └── cids@1.0.0  deduped
  ├─┬ ipfs-unixfs-exporter@3.0.4
  │ └── cids@1.0.0  deduped
  ├─┬ ipld@0.27.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-bitcoin@0.4.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-block@0.10.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-dag-cbor@0.17.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-dag-pb@0.20.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-ethereum@5.0.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-git@0.6.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-raw@6.0.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-zcash@0.5.0
  │ └── cids@1.0.0  deduped
  ├─┬ is-ipfs@2.0.0
  │ └── cids@1.0.0  deduped
  ├─┬ libp2p-delegated-peer-routing@0.7.0
  │ └── cids@1.0.0  deduped
  ├─┬ libp2p-kad-dht@0.20.1
  │ └── cids@1.0.0  deduped
  ├─┬ multiaddr@8.0.0
  │ └── cids@1.0.0  deduped
  └─┬ peer-id@0.14.1
    └── cids@1.0.0  deduped

This is the npm project where I ran the command https://github.com/uprtcl/js-uprtcl/tree/orbit-db-proposals/demos/simple-editor

achingbrain commented 4 years ago

I checked out the repo, did npm i in the simple-editor dir and when I run npm ls cids in that dir I see:

├─┬ @uprtcl/evees@0.0.7-alpha.56
│ └── cids@0.8.3 
├─┬ @uprtcl/evees-ethereum@0.0.7-alpha.56
│ └── cids@0.8.3 
├─┬ @uprtcl/evees-orbitdb@0.0.7-alpha.56
│ └─┬ orbit-db@0.25.3
│   ├── cids@1.0.0  deduped
│   └─┬ orbit-db-io@0.2.0
│     ├── cids@0.7.5 
│     └─┬ ipld-dag-pb@0.18.5
│       └── cids@0.8.3 
├─┬ @uprtcl/evees-polkadot@0.0.7-alpha.56
│ └── cids@0.8.3 
├─┬ @uprtcl/ipfs-provider@0.0.7-alpha.56
│ └── cids@0.8.3 
├─┬ @uprtcl/multiplatform@0.0.7-alpha.56
│ └── cids@0.8.3 
└─┬ ipfs@0.50.1
  ├─┬ cid-tool@1.0.0
  │ └── cids@1.0.0  deduped
  ├── cids@1.0.0 
  ├─┬ dag-cbor-links@2.0.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipfs-bitswap@3.0.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipfs-core-utils@0.4.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipfs-http-client@46.1.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipfs-repo@6.0.3
  │ ├── cids@1.0.0  deduped
  │ └─┬ ipfs-repo-migrations@5.0.5
  │   └── cids@1.0.0  deduped
  ├─┬ ipfs-unixfs-exporter@3.0.4
  │ └── cids@1.0.0  deduped
  ├─┬ ipld@0.27.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-bitcoin@0.4.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-block@0.10.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-dag-cbor@0.17.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-dag-pb@0.20.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-ethereum@5.0.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-git@0.6.1
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-raw@6.0.0
  │ └── cids@1.0.0  deduped
  ├─┬ ipld-zcash@0.5.0
  │ └── cids@1.0.0  deduped
  ├─┬ is-ipfs@2.0.0
  │ └── cids@1.0.0  deduped
  ├─┬ libp2p-delegated-peer-routing@0.7.0
  │ └── cids@1.0.0  deduped
  ├─┬ libp2p-kad-dht@0.20.1
  │ └── cids@1.0.0  deduped
  ├─┬ multiaddr@8.0.0
  │ └── cids@1.0.0  deduped
  └─┬ peer-id@0.14.1
    └── cids@1.0.0  deduped

cids@0.7.5, cids@0.8.3 and cids@1.0.0 are present and they are not compatible with each other. If you could adjust your dependencies so that they all depend on the same version of cids the problem will likely go away.

pepoospina commented 4 years ago

I should have been more clear @achingbrain sorry. I was working with a local version of @uprtcl/evees-orbitdb, not @uprtcl/evees-orbitdb@0.0.7-alpha.56, probably that's why we got different results.

Update. With orbit-db@0.26.0-rc2, which uses ipfs-log@5.0.0 everything works again :).

ping @aphelionz @tabcat

ipfs / js-ipfs