We switched to a monorepo at my last company. I really, really liked it. The reasons why:
When dealing with a frontend and a backend that are disconnected, it makes working with another developer a lot easier. You can both check out the same branch to start, then start building around that feature branch, without managing two different repos feature branches.
It makes using shared components a lot easier. We had a few products that we were working on that shared a lot of components. We tried using a seperate git repo for the components and installing that as a package via npm, but that was impossible to maintain across multiple branches and versions. Once we switched, we just set up a webpack alias and accessing ~components/COMPONENTNAME was all you had to do to get the component. We also did the same for shared Ruby components/classes.
It makes documentation a lot easier too, you can have a separate folder for the documentation at the root level and set up builds based on that folder.
You also don't run into mismatches with the frontend and backend repos, where you haven't checked out the correct branch in one or the other and so don't have something you expect to exist.
There were other benefits, but those were the biggest ones I could think of. I'd be happy to answer any questions about this, if anyone has any!
We didn't use Issues so much, which might be a consideration. This was a for the companies code and so we tracked bugs/issues in a project management tool. I think proper standards and structure can mitigate a lot of that though, especially with Github's new tooling around issues/suggestions.
As far as too much going on, there were a few cases where we could have named something better. Sometimes two projects would have the same file name, and if you weren't paying attention to that, you could edit the wrong code. Better naming/more attention could have fixed that though. From a devops side, I think it made a lot of things easier. New developers could get set up quickly (just a single git clone) and all the code for deploys was in the same repo as the application code.
Whether we use React or Vue or Angular, we will regret it. Instead let’s solve the problem then choose the technology
Interested in UI/UX, design thinking and data visualization
Did you have cases when the shared components needed to be customised ...or put another way were there instances where you had to reduce dependency on the shared components ?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
We switched to a monorepo at my last company. I really, really liked it. The reasons why:
When dealing with a frontend and a backend that are disconnected, it makes working with another developer a lot easier. You can both check out the same branch to start, then start building around that feature branch, without managing two different repos feature branches.
It makes using shared components a lot easier. We had a few products that we were working on that shared a lot of components. We tried using a seperate
gitrepo for the components and installing that as a package vianpm, but that was impossible to maintain across multiple branches and versions. Once we switched, we just set up a webpack alias and accessing~components/COMPONENTNAMEwas all you had to do to get the component. We also did the same for shared Ruby components/classes.It makes documentation a lot easier too, you can have a separate folder for the documentation at the root level and set up builds based on that folder.
You also don't run into mismatches with the frontend and backend repos, where you haven't checked out the correct branch in one or the other and so don't have something you expect to exist.
There were other benefits, but those were the biggest ones I could think of. I'd be happy to answer any questions about this, if anyone has any!
Any problems with issue clutter or generally too much going on in one environment?
We didn't use Issues so much, which might be a consideration. This was a for the companies code and so we tracked bugs/issues in a project management tool. I think proper standards and structure can mitigate a lot of that though, especially with Github's new tooling around issues/suggestions.
As far as too much going on, there were a few cases where we could have named something better. Sometimes two projects would have the same file name, and if you weren't paying attention to that, you could edit the wrong code. Better naming/more attention could have fixed that though. From a devops side, I think it made a lot of things easier. New developers could get set up quickly (just a single
git clone) and all the code for deploys was in the same repo as the application code.Did you have cases when the shared components needed to be customised ...or put another way were there instances where you had to reduce dependency on the shared components ?