4 ms·

It also helps keep people in sync with module and library versions. Without a monorepo, oftentimes what happens is that everybody ends up on different versions

It also helps keep people in sync with module and library versions. Without a monorepo, oftentimes what happens is that everybody ends up on different versions of libraries and modules. For every security update to a library, you'll have to campaign for everyone to pull that fix instead of everyone getting all fixes on every pull. It also forces dealing with incompatibilities between libraries early on when they happen instead of later when they are more entrenched and difficult to fix.

spion 4y ago
That can be handled with alerts and deprecations just like any other library dependencies
- idontknowifican 4y ago
  no it can’t, an alert won’t make a PM allocate time to “tech debt” and these alerts are rarely time free upgrades
  - spion 4y ago
    If you have an issue handling tech debt due to PMs, you'll have that problem with other tech debt too; typically solved by having a better process to handle it
deepsun 4y ago
What I've seen in practice in smaller companies, is actually the other way around: everyone is afraid updating any library version because who knows what other team's work it might break. Theoretically, everyone must have extensive tests to cover everything, but in practice it's hard. But when your team owns a repo, then at least the damage is contained within your team. Google solves that problem with heavy NIH syndrome (its hard to get promoted by utilizing an external third-party lib, better develop your own), and writing tests, yes. And for those few third-party libraries that google still depends on, updating them is a big PITA.
- mping 4y ago
  It's not just NIH, after a certain size every external lib is a liability. You don't want to wait for some OSS maintainer to unblock your multi billion dollar business' issue.
  - ByteJockey 4y ago
    If that were the case, you'd expect to see forking of 3rd party libraries rather than writing of new ones.
    - aeyes 4y ago
      Most of the time you probably only use a small portion of the 3rd party library functionality so forking the whole thing and ripping out everything you don't use or maintaining it doesn't make much sense.

spion 4y ago

That can be handled with alerts and deprecations just like any other library dependencies

idontknowifican 4y ago
no it can’t, an alert won’t make a PM allocate time to “tech debt” and these alerts are rarely time free upgrades
- spion 4y ago
  If you have an issue handling tech debt due to PMs, you'll have that problem with other tech debt too; typically solved by having a better process to handle it

deepsun 4y ago

What I've seen in practice in smaller companies, is actually the other way around: everyone is afraid updating any library version because who knows what other team's work it might break. Theoretically, everyone must have extensive tests to cover everything, but in practice it's hard. But when your team owns a repo, then at least the damage is contained within your team. Google solves that problem with heavy NIH syndrome (its hard to get promoted by utilizing an external third-party lib, better develop your own), and writing tests, yes. And for those few third-party libraries that google still depends on, updating them is a big PITA.

mping 4y ago
It's not just NIH, after a certain size every external lib is a liability. You don't want to wait for some OSS maintainer to unblock your multi billion dollar business' issue.
- ByteJockey 4y ago
  If that were the case, you'd expect to see forking of 3rd party libraries rather than writing of new ones.
  - aeyes 4y ago
    Most of the time you probably only use a small portion of the 3rd party library functionality so forking the whole thing and ripping out everything you don't use or maintaining it doesn't make much sense.