Closed achingbrain closed 4 years ago
Interesting.
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?
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.
π¦π¦π¦ 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
andipfs-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
/docs
to make them more digestible (see https://github.com/libp2p/js-libp2p for an example of this done well)