You can still have all the context in one place, just clone the repos to one folder on your machine, problem solved.
That introduces the problem of coordinating changes between repositories
Everything as code: How we manage our company in one monorepo
81–90 of 232 posts
Re: Everything as code: How we manage our company in one monorepo
#82How do you guys share types between your frontend and backend? I've looked into tRPC, but don't like having to use their RPC system.
I have a library translate the backend types into Typescript. What language do you use on the back?
Re: Everything as code: How we manage our company in one monorepo
#83This article reads like 4o wrote it. It's so exhausting not being able to find content produced by a human being.
Re: Everything as code: How we manage our company in one monorepo
#84This post is obviously (almost insultingly) written by AI. That being said, the idea behind the post is a good one (IaC taken to an extreme). This leaves me at a really weird spot in terms of how I feel about it.
You’d think people would at least spend 2 minutes changing obvious tells like “Why This Matters”…
Re: Everything as code: How we manage our company in one monorepo
#85How do you guys share types between your frontend and backend? I've looked into tRPC, but don't like having to use their RPC system.
Typespec is up and coming. Otherwise there are plenty of options like OpenAPI
Re: Everything as code: How we manage our company in one monorepo
#86Earlier quoted context omitted.
I’m not sure why you made the logical leap from having all code stored in a single repo to updating/deploying code in lockstep. Where you put your code (the repo) can and should be decoupled from how you deploy changes. > you will have the old system using the old schema and the new system using the new schema unless you design for forwards-backwards compatible changes Of course you design changes to be backwards com…
The point is that the realities of not being able to deploy in lockstep erode away at a lot of the claimed benefits the monorepo gives you in being able to make a change everywhere at once. If my code has to be backwards compatible to survive the deployment, then having the code in two different repos isn’t such a big deal, because it’ll all keep working while I update the consumer code.
The point is atomic code changes, not atomic deployments. If I want to rename some common library function, it's just a single search and replace operation in a monorepo. How do you do this with multiple repos?
Re: Everything as code: How we manage our company in one monorepo
#87"Conclusion Our monorepo isn't about following a trend. It's about removing friction between things that naturally belong together, something that is critical when related context is everything. When a feature touches the backend API, the frontend component, the documentation, and the marketing site—why should that be four repositories, four PRs, four merge coordination meetings? The monorepo isn't a constraint. It's…
It wrote the code, so it's best placed to write the copy too.
That is exactly right!
Re: Everything as code: How we manage our company in one monorepo
#8855 business logic services? Sounds extremely overengineered. I'm sure at least half of those services should be consolidated into others.
Re: Everything as code: How we manage our company in one monorepo
#89Earlier quoted context omitted.
We use a mono repo and feature flag new features which gives us the deployment control timing.
What do you use for feature flags?
Not OP, but I think building feature flags yourself really isn’t hard and worth doing. It’s such an important component that I wouldn’t want to depend on a third party
Re: Everything as code: How we manage our company in one monorepo
#90Earlier quoted context omitted.
I like keeping old branches but a lot of places ditch them, never understood why. I also dislike git squash, it means you have to make a brand new branch for your next PR, waste of time when I should be able to pull down master / dev / main / whatever and merge it into my working branch. I guess this is another reason I prefer the forking approach of github, let devs have their own sandbox and their own branches, and…
squash results in a cleaner commit history. at least that’s why we mandate it at my work. not everyone feels the same about it I guess
"squash results in a cleaner commit history" Isn't the commit history supposed to be the history of actual commits? I have never understood why people put so much effort into falsifying git commit histories.