I've used it twice commercially, 1 fail and 1 success.
My TL;DR opinion
For small teams with highly mutable code bases it is convenient, especially in the first couple of stages of life for commercial projects. Less parts, more speed!
For large teams/application it quickly becomes a testing nightmare where everyone hates that team that broke their feature, again.
The large team/application problem can be mitigated, but to do it you need dedicated technical leads or an experienced team on top of enforced standards.
Here are my experiences from different points in my career.
Company 1:
As a intermediate developer i worked in a team of
15-25+ people in a repo', with very unrelated parts that would break frequently when common code was touched. Enforcing coding styles was a nightmare because of how many people you needed to include. The performance was out of control because we could not isolate parts or make informed group decisions on libraries.
Developer experience was from junior to intermediate, and 1 socially inept senior.
Everyone making technical decisions and working their own patterns rather than a common one.
Making releases was problematic, and feature integration bugs were rampant, mitigated by a large QA team.
Worth mentioning, technical leadership was basically non-existent here, leading to constant chaos.
Company 2:
As a senior developer i worked in a team of
10-15 people working in a repo', 3 teams each responsibly for a isolated part of the code-base, and only senior developers with a high focus on performance and maintaining standards, i would go as far and say we had a performance culture.
It worked well, mostly because each part we made was mostly isolated, so breaking unrelated parts was uncommon unless you bodged a bug-fix for a library part.
Technical leadership was also missing in this case, but mitigated by the number of seniors, culture, smaller team and somewhat smaller code-base.
Afaik mon-repo refers to the practice of having all related application code in the one (mono) repo.
vs separating API's, libraries, etc. into different repositories.
Am i wrong about that interpretation?
You are right tho, the first example would not fit that description strictly, as some dependencies were external (Authentication and API).
It did encompass several unrelated web applications in the same codebase however.
My second example contains all the related source code in one repo, so would fit the description more accurately.
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.
I've used it twice commercially, 1 fail and 1 success.
My TL;DR opinion
For small teams with highly mutable code bases it is convenient, especially in the first couple of stages of life for commercial projects. Less parts, more speed!
For large teams/application it quickly becomes a testing nightmare where everyone hates that team that broke their feature, again.
The large team/application problem can be mitigated, but to do it you need dedicated technical leads or an experienced team on top of enforced standards.
Here are my experiences from different points in my career.
Company 1:
As a intermediate developer i worked in a team of
15-25+ people in a repo', with very unrelated parts that would break frequently when common code was touched. Enforcing coding styles was a nightmare because of how many people you needed to include. The performance was out of control because we could not isolate parts or make informed group decisions on libraries.
Developer experience was from junior to intermediate, and 1 socially inept senior.
Everyone making technical decisions and working their own patterns rather than a common one.
Making releases was problematic, and feature integration bugs were rampant, mitigated by a large QA team.
Worth mentioning, technical leadership was basically non-existent here, leading to constant chaos.
Company 2:
As a senior developer i worked in a team of
10-15 people working in a repo', 3 teams each responsibly for a isolated part of the code-base, and only senior developers with a high focus on performance and maintaining standards, i would go as far and say we had a performance culture.
It worked well, mostly because each part we made was mostly isolated, so breaking unrelated parts was uncommon unless you bodged a bug-fix for a library part.
Technical leadership was also missing in this case, but mitigated by the number of seniors, culture, smaller team and somewhat smaller code-base.
I have experienced this. Is it really a mono repo if there is one monolithic application though? One app per repo I would just say is a normal repo.
not really. you can still use monorepo for microservices. since what you want to build based on the path you can mention (mostly) on config.
Can you be more descriptive, how it is it "not really". :)
Afaik mon-repo refers to the practice of having all related application code in the one (mono) repo.
vs separating API's, libraries, etc. into different repositories.
Am i wrong about that interpretation?
You are right tho, the first example would not fit that description strictly, as some dependencies were external (Authentication and API).
It did encompass several unrelated web applications in the same codebase however.
My second example contains all the related source code in one repo, so would fit the description more accurately.