4 ms·

I would not call this a "library", but a set of interrelated project with "shared moduls" instead. With a "library" I mean a piece of code where the publisher d

I would not call this a "library", but a set of interrelated project with "shared moduls" instead. With a "library" I mean a piece of code where the publisher does know who is using it for what exact purpose. Of couse we could now fight over a proper general definition for "library", but this is how I would use the term in this context, because thee long term aspect is what really makes outsourcing such code meaningful -- in contrast to the parents observation that it does not make sense to incorporate foreign code that constantly changes.

mewpmewp2 3y ago
The argument then is also that monorepo allows you to use this as "shared modules" instead of published "libraries". The point is you have some code that you want to reuse, and either within a monorepo or between multiple repositories.
- Archelaos 3y ago
  The question is, when it is wise to do so. Changing the public interface of a "shared module" or published "library" comes with a liability. Code reuse is almost a no brainer in the case of a standard library that rarely or never changes. Using a permanently changing modul whose modifications provide no real benefits for your project makes no economic sense. The sweetspot is somewhere in between. What the parent actually did when copying the library/module code was creating a sort of a a long-term support version for himself maintained by himself. His cost-benefit analysis told him that this is better than always trying to keep up with the changes of the library/modul. My comment was aimed at setting the bar rather high for when to share reusable libraries. And even for my own modules I rather prefer copying code instead of reusing it in different contexts. There is a reason why the contexts differ and it is typically easier and more economic to adress this differences in its particular place instead of preparing for them in shared code. The more up-stream a library/module is, the more general it must be, but the less liable to change it should be.
  - mewpmewp2 3y ago
    With monorepo he wouldn't have had to worry about this decision, since the decision to go back and forth would have been much lower cost. It's low cost decision either way and low cost impact if you make a wrong decision.

mewpmewp2 3y ago

The argument then is also that monorepo allows you to use this as "shared modules" instead of published "libraries". The point is you have some code that you want to reuse, and either within a monorepo or between multiple repositories.

Archelaos 3y ago
The question is, when it is wise to do so. Changing the public interface of a "shared module" or published "library" comes with a liability. Code reuse is almost a no brainer in the case of a standard library that rarely or never changes. Using a permanently changing modul whose modifications provide no real benefits for your project makes no economic sense. The sweetspot is somewhere in between. What the parent actually did when copying the library/module code was creating a sort of a a long-term support version for himself maintained by himself. His cost-benefit analysis told him that this is better than always trying to keep up with the changes of the library/modul. My comment was aimed at setting the bar rather high for when to share reusable libraries. And even for my own modules I rather prefer copying code instead of reusing it in different contexts. There is a reason why the contexts differ and it is typically easier and more economic to adress this differences in its particular place instead of preparing for them in shared code. The more up-stream a library/module is, the more general it must be, but the less liable to change it should be.
- mewpmewp2 3y ago
  With monorepo he wouldn't have had to worry about this decision, since the decision to go back and forth would have been much lower cost. It's low cost decision either way and low cost impact if you make a wrong decision.