Monorepo questions (help wanted)

<p>Hi folks,</p> <p>Traditionally, I&#39;d separate microservices into their own reps. However, I&#39;m attempting to prototype a project using a monorepo. Mostly out of laziness as this repo is for the sakes of some tutorials. I figured it would be easier to keep everything in one place/repo as it would have been a nightmare to demo/run these services locally having separated them all. </p> <p>However, some issues I&#39;ve come up against are; If I use <code>$ go get</code>, it gets confused because it&#39;s looking for the <code>.git</code> directory, which is in the monorepo root directory and not the specific service I&#39;m building. </p> <p>When I try to use <code>$ dep ensure</code> in a Docker container, that seems to work, however it g<code>ets confused about dependencies in the other sub-directories. So for example if I call</code>github.com/go-micro/micro` it resolves it from /vessel-service/vendor instead of /user-service/vendor. It&#39;s really strange... I just wondered if anyone else here had faced these issues?</p> <p>Thanks in advance! </p> <hr/>**评论：**<br/><br/>ionrock: <pre><p>Unless you are committed to writing tooling that is based on a monorepo to ensure you have consistent dependencies (ie shared libraries necessary for interop between services), I&#39;d just make them different repos. You can still create similar consistency checks using github (or whatever repo management system you use) to verify each service is using certain versions. CI is another way you can ensure things are consistent. For example, a global dependency repo can be added to a job that compares the specific repo with a microservice repo and ensures the dependencies are correct. </p> <p>One side effect of microservices is that the services are typically organized according to how they can be deployed. In practice that means having different repos for different services. You can certainly use a monorepo to deploy different microservices, but often times the tooling such as CI systems work much better with single repos per project that you are fighting an uphill battle. The downside of multiple repos is that you need to adopt an &#34;Open Source&#34; mindset in that each project might have different dependencies at different points in time and these dependencies can drift if you&#39;re not careful. None of this is insurmountable and often pushes you towards better practices such as ensuring APIs are where integration happens and not in libraries. </p> <p>I&#39;d also mention that in many companies that have large monorepos, the circumstances were much different than someone today. These companies have internal tools and teams to support them, where it is much more likely you can create a Github organization and utilize the API along side CI to get many of the same benefits without the longer term challenges of managing an extremely large repository. </p></pre>