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.

notnullorvoid 6 hours ago | parent | next [-]

> 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.

▲

verdverm 8 hours ago | parent | prev [-]

> 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)

▲

simonw 7 hours ago | parent | next [-]

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.

▲

bcye 7 hours ago | parent | next [-]

Couldn’t you make a pseudo monorepo via git submodules?

▲

simonw 7 hours ago | parent | next [-]

I don't think there's a way to have that work in Claude Code for web, since each checkout there uses a custom GitHub access token scoped to a single repository.

▲

verdverm 6 hours ago | parent [-]

GitHub tokens can span more than one repo or org if the account requesting has access to them. Is this supported on the non-web version?

(I was going to try claude again this weekend, but when I tried to login, got an error and am reminded how much down time I experience from Anthropic, arg...)

▲

simonw 5 hours ago | parent [-]

The non web version uses whatever credentials you have setup yourself, so it works just fine.

▲

verdverm 5 hours ago | parent [-]

Is that host level or can I provide scoped tokens based on what I'm doing?

In other words, do Anthropic tools provide any affordances for this or is it something I have to manage externally?

	▲	simonw 4 hours ago \| parent [-]
		I'm just talking about the version of Claude Code which runs in containers on their infrastructure here - they call it "Claude Code on the web" (terrible name) and you access it through their native apps or from https://claude.ai/code That product only works against one GitHub repo at a time. The Claude Code you install and run locally doesn't have a GitHub attachment at all and can run against whatever you checkout yourself. Here's an open feature request about it: https://github.com/anthropics/claude-code/issues/23627

▲

verdverm 7 hours ago | parent | prev [-]

Submodules are pain, use the dependency management systems for the languages in your monorepo.

▲

verdverm 7 hours ago | parent | prev [-]

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.

▲

redkoala 7 hours ago | parent | prev [-]

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.

	▲	verdverm 7 hours ago \| parent [-]
		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.