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
Merging repos into ipfs/js-ipfs #2877
Comments
|
Interesting. |
|
Could you please tone done the number of GitHub Releases that you create for every main release? If somebody (for example me I would suggest merging all the |
|
It's kind of a feature, though the GitHub spamming is annoying and the |
Decomposes the main ipfs module into separate core, http api server and cli modules which encapsulate the different parts of ipfs. This allows us to: 1. Omit modules/code/depencies if they aren't going to be used 2. Reduces the amount of tests being run in series I'm hoping this will get us to sub-15 minute builds. Fixes #2678 Fixes #2877
Decomposes the main ipfs module into separate core, http api server and cli modules which encapsulate the different parts of ipfs. This allows us to: 1. Omit modules/code/dependencies if they aren't going to be used 2. Reduces the amount of tests being run in series The average time of a CI job has gone from just under 20 minutes to just over 10 minutes. Outliers here are electron tests (which should be fixed by #3251) and webworker tests which will need further investigation. Fixes #2678 Fixes #2877
Decomposes the main ipfs module into separate core, http api server and cli modules which encapsulate the different parts of ipfs. This allows us to: 1. Omit modules/code/dependencies if they aren't going to be used 2. Reduces the amount of tests being run in series The average time of a CI job has gone from just under 20 minutes to just over 10 minutes. Outliers here are electron tests (which should be fixed by #3251) and webworker tests which will need further investigation. Fixes #2678 Fixes #2877
achingbrain commentedMar 10, 2020
•
edited
Something we've noticed over time is that in order to make any given change to js-IPFS, several repositories must be changed. At the very least to add a new feature, the core needs the implementation, it needs to be exposed in the HTTP API client and tests need to be written in the interface repo. Then assuming you've covered all the test cases and not caused any new bugs the whole lot need to be released together.
Some modules have been split out of other modules because they contain code shared between the core and the HTTP API client. For historical reasons other modules are only used in core, yet sit outside of core.
Our external contributors and feedback from people new to the ecosystem also tells us that contributing to IPFS is not as easy as it could be due to the depth and breadth of the modules in use - it takes a very long time to understand how everything fits together and where to make a given change.
Tests for a given feature do not always reside near the implementation of that feature so it's not always obvious to first time or new contributors what piece of work needs to be done to land a given feature.
Another problem is that a breaking change released in one repo can block releases of other features if, for example, it's discovered that the change needs more work than was originally thought (we're only human after all).
To alleviate some of this pain, we're trialling a lerna-style monorepo, similar to the babel project and others.
This will let us accept one PR that changes the most commonly changed repos, making it easier to make a change, but also to understand the scope of that change. In the worst case reverting changes becomes easier.
The first set of modules to be merged are ipfs/js-ipfs-http-client and ipfs/interface-js-ipfs-core because you typically can't change one without changing the others.
ipfs/js-ipfs-mfs has also been merged in as it's only used by js-ipfs, as have ipfs/js-ipfs-multipart and ipfs/js-ipfs-utils as they only really exist to share code between
ipfs,ipfs-http-clientandipfs-mfs. Other modules may follow, but these are the starting set.All repos that are being merged into this one are gradually having their code, issues and PRs transferred across before being archived. There are lots and lots of these, so it's taking time. Please be patient!
If you spot issues, outdated READMEs, things or directory structures that just don't make sense - PRs are very much appreciated.
We're now using lerna's canary feature to publish release candidates of every successful build of master. Just do
npm install ipfs@nextto get the very freshest, most bleedingest edge ipfs.Refs:
/docsto make them more digestible (see https://github.com/libp2p/js-libp2p for an example of this done well)The text was updated successfully, but these errors were encountered: