Comment by tossandthrow
2 months ago
I have switched entirely away from anything deno, even though I used it in supabase.
But I need to have everything in a mono repo for agents to properly work on in.
Cloud functions and weak desperation between dev and prod is a mess, even more so with agents in the loop.
> But I need to have everything in a mono repo for agents to properly work on in.
Why was this a problem with Deno? Up until recently you had to use package.json and npm/pnpm for it to work, but even then it was better than Bun or Node since you could use import map to avoid compiling packages for testing etc (Node and Bun's type stripping doesn't work across local monorepo dependencies, and tsx produces mangled source maps making debugging a hassle). Now Deno has built-in workspace/monorepo support in deno.json.
> But I need to have everything in a mono repo for agents to properly work on in.
Why is that? Seems like an agent framework limitation, not a reasonable requirement in general. (I do not have this limitation, but I also have a custom agent stack)
I've found myself occasionally wishing I had a monorepo purely for Claude Code for web (Anthropic's hosted version of Claude Code), since it can currently only work with one private repository at a time.
On my own machine I have a dev/ folder full of checkouts of other repos, and I'll often run Claude Code or Codex CLI in that top level folder and tell it to make changes to multiple projects at once. That works just fine.
The "dev/" folder concept is what I give my agent, so I can select what I want it to have access to. On my computer, I have a few of those to group those that go together.
Couldn’t you make a pseudo monorepo via git submodules?
6 replies →
This site (from nx), while biased, explains it best. https://monorepo.tools/
In a poly repo setup, agents are less effective having to infer changes across repo boundaries using specs rather than code as context. Changes that impact multiple repos are also much messier to wrangle.
Monorepos come with a lot of pain too. Two sides of the same coin. I manage the build system for a large monorepo. Questions that will get you to a primary source of pain...
How do you minimally build based on the changeset? How do you know this is sufficient for correctness? What happens when feature branches get out of date and don't see the upstream change that breaks the local branch? How do you version subprojects, as they change or as a whole?
Monorepos have a habit of creating hidden dependencies. The languages you use can help or hurt here.