4 ms·

This isn't recommended practice really and there is nothing about this which justifies having to maintain huge code bases in a single folder or multiple folders

• pavlov 2y ago
  Meta also has a massive monorepo accessed primarily through cloud devservers. When several of the world’s most successful software companies use this approach, it’s hard to argue that it’s inherently bad. Of course it’s sensible to discuss what lessons apply to smaller companies who don’t have the luxury of dedicated tooling teams supporting the monorepo and dev environment.
  • n_ary 2y ago
    Just because some successful companies use some approach doesn't make it the best practice. I have seen firsthand nuisance of monorepo, which took almost 15minutes to correctly switch branches on intel machines(and decently spiked the CPU by causing windows defender to panic). It has decent benefit of easy code sharing, but build and test are soul sucking experiences and if someone decides to run some updated formatter and linter rule accidentally, the whole MR becomes a nightmare to correctly review(once had a 2k+ changes and had to request to rollback and then only commit what they actually wanted to change).
    • aidos 2y ago
      Why would you feel obliged to accept a MR in which someone has accidentally changed large amounts of code?
    • tail_exchange 2y ago
      > took almost 15minutes to correctly switch branches on intel machines This can probably be fixed with trivial tuning. Just configuring Git to fetch only your branches would speed up the branch switching significantly. > build and test are soul sucking experiences Why? It doesn't have to be. If you are going to build the entire monorepo, then yes, but this should only happen when you are running CI, and even then you can break down the builds into smaller components. > the whole MR becomes a nightmare to correctly review Not if you set up code ownership properly. You also need to think what happens in case of emergencies, so having a selected list of "super users" and users with permissions to bypass reviews is important. It sounds like this company wanted a monorepo, but nobody invested any money or time to actually think about developer productivity. When this happens, yes, of course it won't be good, because no project succeeds like this. The nice thing about a monorepo is that instead of 1,000 repos with tooling all over the place and no specialist to take care of them, you can have one repo with really good tooling and a team dedicated to just keep it running smoothly. But if nobody is actually taking care of the monorepo, it will rot just like any other codebase.
    • riwsky 2y ago
      “Someone autoformatted the whole thing under new settings at the same time as introducing a new feature” is hardly a monorepo problem. That could be a pain in the ass to review even in a single file. But the flip-side, of someone cleanly wanting to a do a mass autoformat or autorefactor, is much easier in a monorepo than in split repos.
    • kccqzy 2y ago
      Nothing you describe is inherent to monorepos. Git is slow yes but go use hg. Build and test are slow? That's a CI problem: you didn't allocate enough resources to the build system. Someone ran a formatter accidentally? That's that someone's mistake.
  • mootoday 2y ago
    Meta also uses React and we know what mess that introduced to the world...
• ABS 2y ago
  very much recommended practice by many with, of course, caveats and situations where perfect is the enemy of good, etc, etc e.g. https://trunkbaseddevelopment.com/monorepos/ https://trunkbaseddevelopment.com/monorepos/
• lijok 2y ago
  > Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes. No different to having thousands of smaller repos instead. I personally dislike monorepos, for very niche, in-the-weeds operational reasons (as an infra person), but their ergonomics for DX cannot be understated.
  • __jonas 2y ago
    The 'ergonomics for DX' benefit is that you can share code across projects without having to go down the path of creating a package / library pushed to some internal registry and pulled by each project right? Or are there any other aspects to the monorepo architecture that make it beneficial for large companies like that? Just curious, I've never worked in such an environment myself.
    • dezgeg 2y ago
      In addition to what you mentioned, the ability to atomically commit to a library and all of its consumers. And for a change to a library run the tests of all of its consumers as well.
    • bastawhiz 2y ago
      Every host running a particular commit is running the code you think it is. No submodules or internal packages. If you updated the Button component in the design system, when your commit is deployed, every service that gets deployed has the new button now.
    • triceratops 2y ago
      Dependency versioning is much smoother. Example: Service A requires version 1.1 of libFoo and libFoo 1.1 requires version 0.1 of libBar. But Service A also directly uses libBar version 0.2. Now you have a conflict. If libFoo and libBar are internal code stored in a monorepo they're automatically version-compatible because there is only one version of both.
    • oftenwrong 2y ago
• papruapap 2y ago
  imo monorepos are great, but the tooling is not there, especially the open-sourced ones. Most companies using monorepos have their own tailored tools for it.
• bastawhiz 2y ago
  > Won't be surprised to see that many would probably need a safari map or README documentation in every single folder Is...documentation a bad thing?