Hey guys. Does somebody investigated best-practice...
# help
a
Hey guys. Does somebody investigated best-practices on how to organize multiple repositories and/or libraries in a company? In my company we use a pretty standard stack with NestJS and React, with different teams working on features. We have some backend libraries (for nestjs) and some frontend libraries (for reactjs). But also we have some “standard” libraries which are not dependent on a framework. I want to find a naming convention for the NPM packages, and also for the Git repositories. Also… thinking how to store those packages in Git… I was thinking to create 2 main repositories like “nestjs-common” and “reactjs-common”… and inside will have different folders, one for each package with their own
package.json
(authentication, design library, etc). Other question is.. should I organize projects/packages by technology or by feature? Each of them has good and bad things. I want to discuss this topic and looking for ideas 🙂
Something like this.
a
just do monorepo
a
Hahaha.
I have 2 monorepos in this case.
More details about the organization.
j
Any particular reason you're not doing just one monorepo? Seeing as you are already doing that?
a
Today I have X repos, for X packages.
I’m also thinking on doing 1 monorepo, but I don’t feel good on mixing different technologies.
j
Depends on what you mean by technologies, cos technically both react and nestjs are all JS technology 😛
a
Yeah you are right.
But I would say… different framework, and also frontend/backend.
j
OK gotcha. Yea, for our company, we currently have 3 repos (static infrastructure, backend and frontend). It's that way because of the way serverless framework was originally setup. Eventually we will move to a monorepo for all of it, mainly because it is much simpler to onboard new devs. And also the fact that we can remove the need for doing our complex publishing private packages etc to share between repos. For my own projects, they are basically in a monorepo, and they have been so much easier to get going and setup. Especially when onboarding someone new into the codebase.
a
The problem about monorepo that I don’t like is… maybe you are a backend developer, and you have to pull everyday a lot of changes from frontend projects… which you just don’t care.
And also, if all using the same repo, then 20 developers gets PRs about frontend… and maybe you just have 3 developers which cares about it.
I like that is easier to onboard, but I think is a mess to maintain regarding commits, pull-requests, merges, builds…
j
Yep, gotcha. I guess in our use case, we have a really small team and everyone works on the whole codebase. With regards to PRs, you can use Github actions to automatically assign groups and teams to your PRs. If you want use case in a large company, I believe Facebook for a while there was just in a giant monorepo.
a
Yeah, I think I cant do that with Bitbucket... But also, I dont want to depend on the hosting company, I need a method that can work for any type of Repo.
j
Ah yes... I've given up on that idea. Having been with multiple companies and project(s) the times having to move to another host is exactly once. And it really didn't take that long to move across. The same reason we are now just using AWS primarily and hoping AWS won't just disappear tomorrow :p
a
Hahah yeah.
Well, my devops team is talking about multi-cloud with GCP, haha, that’s why they don’t like CDK.
(but now that CDK for Terraform exists, it’s no problem)