Striving to become a master Go/Cloud developer; Father ๐จโ๐งโ๐ฆ; ๐ค/((Full Stack Web|Unity3D) + Developer)/g; Science supporter ๐ฉโ๐ฌ; https://coder.today
For a normal project, under 5 devs it may be a good approach.
The cons would be:
more complex build pipeline - for example if you have the front end and backend, a push in the backend code would trigger a deploy for the front end.
harder to split to packages/services
impossible build versions/releases
Also I see a pro as "atomic updates". I don't think it is a pro, to get into the projects you do not know, just to update how a library is used. I I think a better approach is to use a dependency by version, and let each user of your project to migrate in its own terms and conditions, and sometimes partially and slowly.
Out of the ordinary: Here is a talk by Google about Googles monorepo
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.
For a normal project, under 5 devs it may be a good approach.
The cons would be:
Also I see a pro as "atomic updates". I don't think it is a pro, to get into the projects you do not know, just to update how a library is used. I I think a better approach is to use a dependency by version, and let each user of your project to migrate in its own terms and conditions, and sometimes partially and slowly.
Out of the ordinary: Here is a talk by Google about Googles monorepo