Monorepo or mutiple repositories?
Last comment by
With our current architecture we're facing a crossroad, where we need to talk about how could be the best approach to handling all the git repositories and all the problems that we're having right now and the problems to come. Starting point On one hand, this is the picture right now: Official modules on decidim/decidim decidim-accountability decidim-admin decidim-api decidim-assemblies decidim-budgets decidim-comments decidim-core decidim-dev decidim-meetings decidim-pages decidim-participatory_processes decidim-proposals decidim-surveys decidim-system decidim-verifications Official modules outside decidim/decidim decidim-module-consultations decidim-module-sortitions decidim-initiatives decidim-results decidim-module-blogs decidim-module-mentions Non official modules Census (DIBA) Crowdfundings (podemos-info) DataViz (Barcelona) Debates (Barcelona) Members (FundAction) Pol.is (OSP) Surveys (Hospitalet) User Export (OSP) Verification Census API (DIBA) Verification Census API (Barcelona) Votings (podemos-info) Two possible roads Monorepo This is mostly how we're working right now. The only difference between what belongs on decidim/decidim right now are not technical issues but mostly administrative reasons (which company has made that development). This would involve moving all the Official modules outside decidim/decidim to Official modules on decidim/decidim. Pros This is simpler, specially because it allows the APIs to change on any given moment and make that change on a single PR, and all the CI and translations on the same place. Also simpler to grep. A couple big companies that had this model are Google and Facebook. More info: https://danluu.com/monorepo/ Cons This doesn't scale that well (lots of LOC for every module, lots of times to CI to finish). Multiple repos Most of the modules of Official modules on decidim/decidim should go outside, leaving a leaner core module: decidim-admin decidim-api decidim-core decidim-dev decidim-pages decidim-system All the other modules would be on separate repositories. Pros Allows to make the APIs between modules more mature, allow better scaling. Cons This have some pain points, regarding: Translations: we should create a new crowdin project with their integration CI: configure again. Maybe with dummy apps and default configs it's a little less pain Docs? Issues Having somekind of generators or a skeleton on making a new gem would reduce these pain points.
Report inappropriate content
Is this content inappropriate?
What is the summary or conclusion of this debate?