Business logic belongs in services, not libraries. If you're copying nontrivial business logic into different services, that's a big red flag; you need to pick a service to be the single source of truth for that business logic and have other services call into it.
edit: Libraries don't solve this, to be clear. Let's say you have 100 services that reference `someUtilityFunction()` in SharedLib==1.0. Oops, there's a bug! OK, let's publish SharedLib==1.1. Great... now you still need to go and update, test, and deploy 100 different services, because they're not going to pick up the corrected business logic otherwise. And of course, you might have the case where someone got lazy and didn't upgrade and they're still using SharedLib==0.0.1-alpha, and there's a bunch of breaking library changes that happened between that version and 1.0 that were never implemented...
> Libraries don't solve this, to be clear. Let's say you have 100 services that reference `someUtilityFunction()` in SharedLib==1.0. Oops, there's a bug! OK, let's publish SharedLib==1.1. Great... now you still need to go and update, test, and deploy 100 different services, because they're not going to pick up the corrected business logic otherwise. And of course, you might have the case where someone got lazy and didn't upgrade and they're still using SharedLib==0.0.1-alpha, and there's a bunch of breaking library changes that happened between that version and 1.0 that were never implemented...
Yeah, but that relies on a lot of "ifs" when a bugfix is done.
If the services don't have tests before deployment, you'll have problems.
If a rarely-updated service doesn't get the fix, you have problems.
If someone got lazy and didn't upgrade (how is that even possible? they don't have to do anything to get the new thing other than rebuild, redeploy) you'll have problems.
OTOH, there's no "ifs" about getting a bugfix when they're all using the same copy of `someFunction()`.
When they're all using the same copy of `someFunction()`, the bugfix will go in with the next build of their service, without them even knowing.
After all, you don't have each team keep their own copy of the kernel, do you?
If you require all services to constantly be updated with the latest versions of libraries, you've built a distributed monolith, which is generally acknowledged as being far worse than both independent services and an actual monolith.
So what's the plan when some services think that's a bug and others think it's a feature? You fix some and break others.
So you can make a new function. Maybe one calls the other. They do nearly the same thing but not quite. Some dependencies move to the new one, some don't.
Or you version the library. Shortly after, people want mixes of behaviour from different libraries, and someone else wants two dependencies that each want different versions of the library.
I don't have a good recommendation here but silently changing the behaviour of libraries is not necessarily a better play than not doing that.
edit: Libraries don't solve this, to be clear. Let's say you have 100 services that reference `someUtilityFunction()` in SharedLib==1.0. Oops, there's a bug! OK, let's publish SharedLib==1.1. Great... now you still need to go and update, test, and deploy 100 different services, because they're not going to pick up the corrected business logic otherwise. And of course, you might have the case where someone got lazy and didn't upgrade and they're still using SharedLib==0.0.1-alpha, and there's a bunch of breaking library changes that happened between that version and 1.0 that were never implemented...