I'd like to propose we move the typescript-client repo into the software-agent-sdk repo to ease the release process. Any objections?

🐾 No objection to the move — the consumer blast radius is small: agent-canvas is the only heavy user (pins

@openhands/typescript-client@1.28.0

, imported across ~48 files), plus vulnerability-fixer via a

git+https

dep. automation and odie don't use it at all. So folding it into software-agent-sdk to release the mirror in lockstep makes sense. One thing to check before/while doing it: the versioning is already inconsistent — the repo's package.json says

0.1.1

, newest tag is

v0.6.0

, but agent-canvas pins

1.28.0

. Whatever the move does, the SDK-repo release needs to keep publishing

@openhands/typescript-client

to GitHub Packages at a version those two consumers can still resolve (the pinned

1.28.0

and the git URL), or install breaks. If the package now shares the SDK's version, worth a note on how existing pins migrate. (Made a short teach-me page on what the client is + this proposal, for anyone ramping: https://enyst.github.io/arch/teach-typescript-client.html )

This feels a bit strange to me...two different programming languages in the same repo, and they will fall out of sync unless we enforce that every change to agent-server comes with a corresponding change to typescript-client

It's because typescript client should strictly sync versions with agent server and if we have them in the same repo we only need half the PRs. Does two PLs in the same repo seen that weird? I think monorepos with different languages are pretty common

My fear is slowing down agent-server. If every time someone wants to change agent-server, they are forced to also make and test changes to typescript-client, that's a constant tax Today, typescript-client can lag behind for a while, and then get caught up in a single PR

Would having them in the same repo preclude that though? It gives the option to bump them in the same PR, it doesn't require it. Also even if it did require it, client version bumps are pretty trivial with agents

Yeah I suppose you could still let it lag...but that's a monorepo antipattern IIUC With repo boundaries, there's a natural tension between keeping things in sync, and commingling work. Separate repos, and you pay a small, constant sync tax; combine them, and you pay an ill-defined tax in the form of comingled issues/PRs, longer CI/CD, larger PRs, etc

I think I’m particularly feeling the pain because our review bot isn’t working now so I can’t merge PRs without another human blocking. If we set update to be automatic that’d reduce the pain a bit, but we still have the sdk -> typescript -> canvas dependency chain which feels very inefficient

ahhh yeah that's painful. What's the LOE on fixing reviewbot?

I wonder if we should have an owner, or put squasher on it

Or maybe we could have a fallback, like Rohit had done with one of the repos: a label, running the reviewer agent on a remote VM 🤔

Not a bad idea Engel, but I think ideally we’ll fix the problem fundamentally, as this might also be affecting others