We have this problem at Mozilla. The Firefox codebase is a monorepo and source of truth for the WebRender project which lives in a subtree. The source of truth used to be a separate github repo and it was synced into the monorepo regularly but we flipped that around and now we sync back out to the github repo. PRs do come in against the github repo and we have a bit of ad-hoc tooling that imports the PR into our monorepo's code submission flow (bugzilla+phabricator). It lands in the monorepo assuming it passes review and tests, and then gets synced back to the github repo.
That being said the tooling we have is not great - there's still some manual steps in this flow, and it's not ideal.
For the webgpu project that's in a similar situation but gets a lot more external contributions, we will eventually try some sort of two-way sync.
So sorry I don't have a good solution for you but you're not alone with respect to this problem :)
Thanks for the insight. Good to know I'm not alone.
It feels orders of magnitude easier to make the internal repo the source of truth when developing and a huge sacrifice to productivity to split something out.
If there was a good solution I think it could really help allowing more open source company sponsored projects to get out there in the wild.
Wouldn't it be possible to flip things around, e.g. source of truth is a standalone public repo, that gets forked into the monorepo? So you could thne make changes internally, and then afterwards isolate the library changes and push them upstream
idk how monorepos work really so maybe im way wrong
That being said the tooling we have is not great - there's still some manual steps in this flow, and it's not ideal.
For the webgpu project that's in a similar situation but gets a lot more external contributions, we will eventually try some sort of two-way sync.
So sorry I don't have a good solution for you but you're not alone with respect to this problem :)