Skip to content
This repository has been archived by the owner on Feb 12, 2024. It is now read-only.

Merging repos into ipfs/js-ipfs #2877

Closed
31 of 33 tasks
achingbrain opened this issue Mar 10, 2020 · 3 comments · Fixed by #3288
Closed
31 of 33 tasks

Merging repos into ipfs/js-ipfs #2877

achingbrain opened this issue Mar 10, 2020 · 3 comments · Fixed by #3288

Comments

@achingbrain
Copy link
Member

achingbrain commented Mar 10, 2020

📦📦📦 So many modules

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).

💕 What are we doing about it?

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-client and ipfs-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.

🎁 Bonus

We're now using lerna's canary feature to publish release candidates of every successful build of master. Just do npm install ipfs@next to get the very freshest, most bleedingest edge ipfs.

Refs:

✅ Status

@whyrusleeping
Copy link
Member

Interesting.

@AuHau
Copy link
Member

AuHau commented Apr 9, 2020

Could you please tone done the number of GitHub Releases that you create for every main release? If somebody (for example me 😅 ) Watch this Repo for Releases, he gets quite spammed by these new releases.

I would suggest merging all the *-example-* releases to one ipfs-examples release?

@achingbrain
Copy link
Member Author

achingbrain commented Apr 9, 2020

It's kind of a feature, though the GitHub spamming is annoying and the example-* releases are just noise in the release list. I'll see if I can scope the publish step to the ipfs* modules.

achingbrain added a commit that referenced this issue Sep 15, 2020
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
achingbrain added a commit that referenced this issue Sep 28, 2020
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 achingbrain unpinned this issue Oct 12, 2020
SgtPooki referenced this issue in ipfs/js-kubo-rpc-client Aug 18, 2022
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
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants