search

diia-open-source / diia-setup-howto

41 stars 4 forks source link

Why single-repo-per-project structure? #2

Open XBeg9 opened 8 months ago

XBeg9 commented 8 months ago

I've noticed that the project currently follows a traditional single-repo-per-project structure. However, I believe that migrating to a monorepo approach could offer several benefits for the project's development and collaboration process.

A monorepo setup would allow us to consolidate all related projects or components into a single repository, streamlining development workflows, enhancing code sharing and reusability, and improving collaboration among contributors.

I propose adding support for a monorepo structure to the project, enabling us to leverage the advantages it offers. This could involve restructuring the repository, updating development guidelines, and implementing tooling to facilitate monorepo management.

By adopting a monorepo approach, we can make it easier for developers to contribute to multiple projects within the repository, simplify dependency management, and improve the overall efficiency of the development process.

https://github.com/diia-open-source/diia-setup-howto/blob/36b53795e26b44ef9d5ae7e83b9f19936f39ec55/backend/LINKDEPS.md?plain=1#L5

Some additional links/resources about monorepo https://monorepo.tools/.

alinkedd commented 8 months ago

@XBeg9,

I assume possible answers to your question might include:

It seems that a monorepo would naturally fit here, though I'm not sure considering the current number of repositories and the amount of code within each. I believe it would be nice to just publish these packages as @diia-open-source/<package>, especially since they are open source now.

P.S. btw, it's interesting whether devs actually use linking instead of a private npm registry internally, or if this is just an instruction for open-source users.

XBeg9 commented 8 months ago

@XBeg9,

I assume possible answers to your question might include:

  • requirement for per-repo access/permissions
  • simplicity of security evaluation
  • need for teams to work independently, including releases and tagging
  • devs used a monorepo, but it was problematic, so they broke it into multiple repositories

It seems that a monorepo would naturally fit here, though I'm not sure considering the current number of repositories and the amount of code within each. I believe it would be nice to just publish these packages as @diia-open-source/<package>, especially since they are open source now.

P.S. btw, it's interesting whether devs actually use linking instead of a private npm registry internally, or if this is just an instruction for open-source users.

Maintaining separate modules or services for enhanced security and independent solutions is commendable. However, considering the openness of this project, wouldn't consolidating everything under a unified @diia-open-source/ monorepo umbrella enhance accessibility and streamline collaboration?

kant2002 commented 8 months ago

I trying to build source code and hit different kind of NPM issues. For example https://github.com/npm/cli/issues/5007

alinkedd commented 7 months ago

@XBeg9

Everything has its pros and cons. It's understandably easier to comprehend a monorepo project at first. And it seems easier to collaborate on until it gets too big. IMHO, working every day with 30 packages (plus additional clients and potentially more) in one repository is enough to get mentally overwhelmed and make a mistake. Ideally, I would opt for a hybrid approach, meaning cohesive packages are grouped into respective repos, though it can be trickier to set it up appropriately.