-
Notifications
You must be signed in to change notification settings - Fork 1.2k
webui and ipfs-desktop do depend on js-ipfs/js-ipfs-http-api #2542
Comments
These modules need to declare which versions of IPFS and/or the HTTP API client they are compatible with, even if it's just for their tests, otherwise they risk depending on features that may not be available at runtime and suffering other hard to replicate bugs. cc @hacdias @olizilla webuiWe could add Otherwise the webui end to end tests could be configured to run against an actual IPFS instance, the version of which is declared in ipfs-desktopThis module should pass a known version of If it just takes whatever webui on the gateway
This is true, but we resolve the This is a gap though, maybe we could figure out a way of running the webui tests with the current branch head as part of a release. Might involve doing something clever with
|
Goes some way to address ipfs/js-ipfs#2542 in that it changes our definition of how a module 'depends' on IPFS. If it's in your `node_modules` folder, it'll get upgrade to the current release we are testing. This means if we're testing module `A` and `A` has a depdendency graph like `A -> B -> C -> ipfs`, as long as `ipfs` has been hoisted to the the top level `node_modules` folder, we'll swap it out with the new version we're trying to release. It also dedupes `ipfs` and `ipfs-http-client` in the dep tree so we can be sure we're testing against our `rc`, though this may cause problems where intermediate deps need updating, but at least the need for them to be updated will be visible.
We should only tests direct dependents!! |
FYI that this issue is no longer relevant since we're pulling js-ipfs out of webui and desktop (ipfs/kubo#9125). closing this. |
From https://github.com/ipfs/js-ipfs/blob/master/docs/RELEASE_ISSUE_TEMPLATE.md
I don't believe this is correct. Because:
also:
The text was updated successfully, but these errors were encountered: