>We must be precise in our language

I am talking about using a shared software repository as a dependency. Which is valid for a microservice. Taking said dependency does not turn a microservice into a monoloth.

It may be a build time dependency that you do in isolation in a completely unrelated microservice for the pure purpose of building and compiling your business microservice. It is still a dependency. You cannot avoid dependencies in software or life. As Carl Sagan said, to bake an apple pie from scratch, you must first invent the universe.

>The worst systems I have ever worked on were "microservices" with shared libraries.

Ok? How is this relevant to my point? I am only referring to the manner in which your microservice is referencing said libraries. Not the pros or cons of implementing or using shared libraries (e.g mycompany-specific-utils), common libraries (e.g apache-commons), or any software component for that matter

>Yes, exactly

So you're agreeing that there is no such thing as a microservice. If that's the case, then the term is pointless other than a description of an aspirational yet unattainable state. Which is my point exactly. For the purposes of the exercise described the software is a microservice.

> Taking said dependency does not turn a microservice into a monoloth.

True. However one of the core tenets of microservices is that they should be independently deployable[1][2].

If taking on such a shared dependency does not interfere with them being independently deployable then all is good and you still have a set of microservices.

However if that shared dependency couples the services so that if one needs a new version of the shared dependency then all do, well you suddenly those services are no longer microservices but a distributed monolith.

[1]: https://martinfowler.com/microservices/

[2]: https://www.oreilly.com/content/a-quick-and-simple-definitio...