[JavaScript] Mono Repos

[dignifiedquire]

In the past weeks there has been a growing pain for developer of js-ipfs, js-libp2p and all associated modules due to the amount of different packages and modules. As these modules are very connected and have often strong dependencies on each other in terms of public api, changing those is a long and complicated process currently.

The second pain point we have seen is a confusion of developers trying to find some details about the project, and not knowing where to go, given that there are so many different repos each with their own specific functionality and scope.

I want here to start a discussion around a mono repos, which have been used in the JavaScript community successfully to ease some of these pains, while still maintaing to have code modularised and published into many individual packages onto npm. Two examples of this are pouchdb and babel.

Please share your thoughts, fears and pain points below :)

[victorb]

Let's do cons/pros!

Pros for having a monolith project

• Easier to find related projects, all of them are together
• Easier to follow the code, everything comes from the same root
• Faster to install/develop, git clone && npm install and you should have most you need for overall project contribution.
• Features that are cross-modules becomes easier to implement (right now we need to coordinate PRs across many repos)
• Testing across the projects and code sharing becomes a lot easier

Cons for having a monolith project

• Modularity will suffer a bit, easier to skip out on modularization
• We have to introduce some monorepo-management tool (like https://github.com/chandlerprall/shrine or similar)
• Not entirely establish praxis in the community regarding monorepos, but some big projects are doing it (in addition to pouchdb and babel, lodash and react does the same)
• Need to clone a lot of code to contribute to one module

Some quick thoughts, might be expanded later on. Let me know if there is something I wrote that is completely wrong.

[whyrusleeping]

Cons

• CI will have to test entire repo for small changes in one subpackage
• Makes it easy to be lazy about not writing readmes and proper documentation
• makes it much more difficult for users to write their own packages to plug in (writing a new transport on the go side would be impossible without it being nicely broken out)
• Finding things is really not easier.

[jbenet]

No. We're just finally getting away from the pain of the massive go-ipfs repo-- where all issues and code is so hard to navigate. js-ipfs has the pleasant state that all issues, CI, PRs, commit access, etc., are well-scoped to the repos they belong to, and contributors need only understand small pieces at a time.

Modularization for us is about carefully scoping issues, CI, permissions, READMEs, and so on. Not just about publishing to npm. This is absolutely key for the reuse of our modules in other projects.

Ways to achieve what you want:

• Use org-wide github search. You already have to do this.
• Use a directory with a shell script that clones all repos into it. Or use git submodules.
• Use hub to automate pull requests.

[daviddias]

We are not going to pursue monorepo structures for all the cons presented. Closing this issue for now.