5 ms·

I don't understand how come monorepos never just got "solved", and why git didn't expand in that direction. I switched from a company with a monorepo to one wi

• fcarraldo 1mo ago
  I work at a monorepo company and any time someone gets to work on a project that necessitates working outside of the monorepo, it's a night-and-day improvement. Tools, especially open source ones (linters, static analysis, scanning, LSPs, IDEs, etc) are not built for monorepos, and with AI Agents working in the monorepo results in an enormous increase in input tokens as the agents are constantly trying to grep this giant source tree. I'm sure it's possible that we're doing the monorepo thing wrong, but I'm genuinely curious what the upside is that you're experiencing? Or are these drawbacks unique to our implementation?
  • plumeria 1mo ago
    > Tools, especially open source ones (linters, static analysis, scanning, LSPs, IDEs, etc) are not built for monorepos, and with AI Agents working in the monorepo results in an enormous increase in input tokens as the agents are constantly trying to grep this giant source tree. I've been thinking that one could dynamically patch .claude/settings.json (or its equivalent for other agents) to allow reads/writes only to the active app/package being edited and its dependencies (other packages/apps).
    • fcarraldo 1mo ago
      You can, if you have a trusted build graph. I know that “cone-shaped” checkout tools like this are common in monorepo environments, but unfortunately there aren’t any maintained open source implementations that I’m aware of.
    • handfuloflight 1mo ago
      This is a great idea.