I’m not sure how seemingly most of us forgot about the context window being a finite _window_.
“It’s all there Claude just read it.”
Ok…
Everything as code: How we manage our company in one monorepo
191–200 of 232 posts
Re: Everything as code: How we manage our company in one monorepo
#192I have a question about Monorepo. Do companies really expose their entire source code all in one repo for their devs to download ? I understand that people can always do bad things if they want but with monorepo, you are literally letting me download everything right ?
While not talked about on HN as much, the big corps doing monorepo use something like Perforce which has "protects" tables allowing very granular access control
Re: Everything as code: How we manage our company in one monorepo
#193This is sort of a whole product , but it’s hardly managing the whole company . Financials? HR? Contracts? Pictures of the last team meeting? It just looks like a normal frontend+backend product monorepo, with the only somewhat unusual inclusion of the marketing folder.
It's worth noting with a few clicks from the linked article, you can find that this company is (at least according to LinkedIn) a single person. Which explains how the whole company can fit into a repo. But also makes you question how valuable the "insights" here are, like obviously a single-person project should be using a monorepo...
have you ever heart that google is also one repo? at least it was until 2015. don’t know the story later. So it doesn’t have to be one person company. yet they are making billions
Re: Everything as code: How we manage our company in one monorepo
#194I promise I only self promote when it is relevant, but this is exactly what I am building https://nimbalyst.com/ for. We build a user-friendly way for non-technical users to interact with a repo using Claude Code. It's especially focused on markdown, giving red/green diffs on RENDERED markdown files which nobody else has. It supports developers as well, but our goal is to be much more user friendly than VSCode forks.…
> Nimbalyst is SOC-Type 2 certified
What does this mean in context of downloadable desktop apps?
Re: Everything as code: How we manage our company in one monorepo
#195Earlier quoted context omitted.
Atomic changes are a lie in the sense that there is no atomic deployment of a repo. The moment you have two production services that talk to each other, you end up with one of them being deployed before the other.
Atomicity also rarely matters as much as people think it does if contracts are well defined and maintained.
A selling point of monorepos is that you don't need to maintain backwards compatible contracts and can make changes to both sides of an API at once.
Re: Everything as code: How we manage our company in one monorepo
#196Earlier quoted context omitted.
> including "no development branches" Can you explain this comment? Are you saying to develop directly in the main branch? How do you manage the various time scales and complexity scales of changes? Task/project length can vary from hours to years and dependencies can range from single systems to many different systems, internal and external.
Yeah, all new commits are merged to main. The complexity comes from releases. Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it. Then development continues until commit 234, but your service is still at 123. Some critical bug is found, and fixed in commit 235. You can't just redeploy at 235 since the in-between may include development of new features that a…
That's where tags are useful because the only valid operations (depending on force push controls) are creating a new tag. If your release process creates tag v0.6.0 for commit 123 your tools (including `git describe`) should show that as the most recent release, even at commit 234. If you need to cut a hotfix release for a critical bug fix you can easily start the branch from your tag: `git switch -c hotfix/v0.6.1 v0.6.0`. Code review that branch when it is ready and tag v0.6.1 from its end result.
Ideally you'd do the work in your hotfix branch and merge it to main from there rather than cherry picking, but I feel that mostly because git isn't always great at cherry picking.
Re: Everything as code: How we manage our company in one monorepo
#197Earlier quoted context omitted.
Squashing only results in a cleaner commit history if you're making a mess of the history on your branches. If you're structuring the commit history on your branches logically, squashing just throws information away.
I’m all ears for a better approach because squashing seems like a good way to preserve only useful information. My history ends up being: - add feature x - linting - add e2e tests - formatting - additional comments for feature - fix broken test (ci caught this) - update README for new feature - linting With a squash it can boil down to just “added feature x” with smaller changes inside the description.
You can always take advantage of the graph structure itself. With `--first-parent` git log just shows your integration points (top level merge commits, PR merges with `--no-ff`) like `Added feature X`. `--first-parent` applies to blame, bisect, and other commands as well. When you "need" or most want linear history you have `--first-parent` and when you need the details "inside" a previous integration you can still get to them. You can preserve all information and yet focus only on the top-level information by default.
It's just too bad not enough graphical UIs default to `--first-parent` and a drill-down like approach over cluttered "subway graphs".
Re: Everything as code: How we manage our company in one monorepo
#198Earlier quoted context omitted.
> including "no development branches" Can you explain this comment? Are you saying to develop directly in the main branch? How do you manage the various time scales and complexity scales of changes? Task/project length can vary from hours to years and dependencies can range from single systems to many different systems, internal and external.
Yeah, all new commits are merged to main. The complexity comes from releases. Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it. Then development continues until commit 234, but your service is still at 123. Some critical bug is found, and fixed in commit 235. You can't just redeploy at 235 since the in-between may include development of new features that a…
> Suppose you have a good commit 123 were all your tests pass for some project, you cut a release, and deploy it.
And you've personally done this for a larger project with significant amount of changes and a longer duration (like maybe 6 months to a year)?
I'm struggling to understand why you would eliminate branches? It would increase complexity, work and duration of projects to try to shoehorn 2 different system models into one system. Your 6 month project just shifted to a 12 to 24 month project.
Re: Everything as code: How we manage our company in one monorepo
#199Earlier quoted context omitted.
It's worth noting with a few clicks from the linked article, you can find that this company is (at least according to LinkedIn) a single person. Which explains how the whole company can fit into a repo. But also makes you question how valuable the "insights" here are, like obviously a single-person project should be using a monorepo...
have you ever heart that google is also one repo? at least it was until 2015. don’t know the story later. So it doesn’t have to be one person company. yet they are making billions
Google isn’t a monorepo since the acquisition of Android. That one never made it into google3.
Re: Everything as code: How we manage our company in one monorepo
#200Earlier quoted context omitted.
It's worth noting with a few clicks from the linked article, you can find that this company is (at least according to LinkedIn) a single person. Which explains how the whole company can fit into a repo. But also makes you question how valuable the "insights" here are, like obviously a single-person project should be using a monorepo...
have you ever heart that google is also one repo? at least it was until 2015. don’t know the story later. So it doesn’t have to be one person company. yet they are making billions
I'm not making any claims about monorepo being good or bad and I'm fully aware large companies have monorepos (or at least very large repos). I'm saying that the fact it's a one-person "company" needs to be taken into account when talking about how applicable their experience is to other companies.