A while back, I wrote a post about the problem of inappropriately DRY (Don't Repeat Yourself) code. In that post, I attempted to demonstrate, by allegory, the dangers inherit in sharing code that should not be shared. But, I don't think that I clearly articulated the core problem. Recently, however, I was watching a ReactJS video by Michael Chan and I think he very perfectly summed-up exactly what I was trying to say: Components should be reused, not repurposed.
At InVision App, I believe (though lack sufficient evidence) that a large portion of the bugs that make it into production suffer from this exact problem. Components that are being "repurposed" when they shouldn't be. Then, when the shared code gets changed in one place, it has a deleterious effect in other areas of the application because those other areas weren't built to handle the new behavior or component API contract.
I think this is why we often see utilities, like Lodash, getting shared across applications while business objects like "User" or "Account" are not. The nature of Lodash doesn't have to be repurposed from application to application. But, something like "User" can't simply be "reused." The meaning of User in one application is different than it is in another application. And to try and share this code would lead to repurposing, not reusing.
Anyway, the concept of reuse vs. repurpose just felt so good that I wanted to pass it on.
Actually, as a final note, I think that repurposing often comes from going too high in the component tree. If you have a component that feels like it is being repurposed, I think that you will often be able to drop one layer down in order to find components that can be reused. Recombining reusable components, in a new context, is more work in the short terms. But, this will lead to less work in the long run as fewer bugs emerge and maintenance becomes easier.