Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Everything as code: How we manage our company in one monorepo

kasava.dev

Post reply on HN
Print view View original

91–100 of 232 posts

Re: Everything as code: How we manage our company in one monorepo

#91

Post by Etheryte »

Arainach wrote: post #75
Etheryte wrote: post #44

Earlier quoted context omitted.

So in short you don't share types. Manually writing them for both is easy, but also tedious and error prone.

Each layer of your stack should have different types. Never expose your storage/backend type. Whenever you do, any consumers (your UI, consumers of your API, whatever) will take dependencies on it in ways you will not expect or predict. It makes changes somewhere between miserable and impossible depending on the exact change you want to make. A UI-specific type means you can refactor the backend, make whatever change…

This completely misses the point of what sharing types is about. The idea behind sharing types is not exposing your internal backend classes to the frontend. Sharing types is about sharing DTO definitions between the backend and the frontend. In other words, sharing the return types of your public API to ensure when you change a public API, you instantly see all affected frontend code that needs to be changed as well. No one is advocating for sharing internal representations.

Re: Everything as code: How we manage our company in one monorepo

#92

Post by talos »

Escapade5160 wrote: post #83

This article reads like 4o wrote it. It's so exhausting not being able to find content produced by a human being.

Yeah it reads like it, and if a random AI detector (GPTZero) is to be believed it's pretty much all AI generated.

Crazy that nobody can be bothered to get rid of the obvious AI-isms "This isn't just for...", "The Challenges (And How We Handle Them)", "One PR. One review. One merge. Everything ships together." It's an immediate signal that whoever wrote this DGAF.

Re: Everything as code: How we manage our company in one monorepo

#93

Post by mjr00 »

valicord wrote: post #86
ajanuary wrote: post #47

Earlier quoted context omitted.

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?

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

Multiple repos shouldn't depend on a single shared library that needs to be updated in lockstep. If they do, something has gone horribly wrong.

Re: Everything as code: How we manage our company in one monorepo

#94

Post by rezonant »

GeneralMayhem wrote: post #48
lorey wrote: post #30

Earlier quoted context omitted.

Very interesting points. Would you mind sharing a few examples of when cherry-picking is necessary and why atomic changes are a lie? I'm using a monorepo for my company across 3+ products and so far we're deploying from stable release to stable release without any issues.

Do you take down all of your projects and then bring them back up at the new version? If not, then you have times at which the change is only partially complete.

Nah, these days the new thing is Vibe Deployments, just ship the change and pray.

Re: Everything as code: How we manage our company in one monorepo

#95

Post by normie3000 »

giancarlostoro wrote: post #16
eddd-ddde wrote: post #10

I am a huge monorepo supporter, including "no development branches". However there's a big difference between development and releases. You still want to be able to cut stable releases that allow for cherrypicks for example, especially so in a monorepo. Atomic changes are mostly a lie when talking about cross API functions, i.e. frontend talking to a backend. You should always define some kind of stable API.

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…

> you have to make a brand new branch for your next PR

Is there overhead to creating a branch?

Re: Everything as code: How we manage our company in one monorepo

#96

Post by literallyroy »

Denvercoder9 wrote: post #31
sallveburrpi wrote: post #26

Earlier quoted context omitted.

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

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.

Re: Everything as code: How we manage our company in one monorepo

#97

Post by awesome_dude »

GeneralMayhem wrote: post #48
lorey wrote: post #30

Earlier quoted context omitted.

Very interesting points. Would you mind sharing a few examples of when cherry-picking is necessary and why atomic changes are a lie? I'm using a monorepo for my company across 3+ products and so far we're deploying from stable release to stable release without any issues.

Do you take down all of your projects and then bring them back up at the new version? If not, then you have times at which the change is only partially complete.

People that Blue Green are doing that, aren't they?

Canary/Incremental, not so much

Re: Everything as code: How we manage our company in one monorepo

#98

Post by lawrjone »

talos wrote: post #92
Escapade5160 wrote: post #83

This article reads like 4o wrote it. It's so exhausting not being able to find content produced by a human being.

Yeah it reads like it, and if a random AI detector (GPTZero) is to be believed it's pretty much all AI generated. Crazy that nobody can be bothered to get rid of the obvious AI-isms "This isn't just for...", "The Challenges (And How We Handle Them)", "One PR. One review. One merge. Everything ships together." It's an immediate signal that whoever wrote this DGAF.

I hadn't come across GPTZero before and wondered if it worked. Just testing on a sample of my blog posts (I do one each year) I got a 100% AI generated mark for a post in... 2022, and 2023. Both before AI tools were around.

Not to say this post isn't AI generated but you might want a better tool (if one exists)

Re: Everything as code: How we manage our company in one monorepo

#99

Post by teekert »

talos wrote: post #92
Escapade5160 wrote: post #83

This article reads like 4o wrote it. It's so exhausting not being able to find content produced by a human being.

Yeah it reads like it, and if a random AI detector (GPTZero) is to be believed it's pretty much all AI generated. Crazy that nobody can be bothered to get rid of the obvious AI-isms "This isn't just for...", "The Challenges (And How We Handle Them)", "One PR. One review. One merge. Everything ships together." It's an immediate signal that whoever wrote this DGAF.

Pff the mental list of what I can’t use when I write is getting pretty big. Em dashes are done for, as are deep dives, delving, anything too enthusiastic, and Oxford commas…

A text either has value to you or it doesn’t. I don’t really understand what the level of AI involvement has to do with it. A human can produce slop, an AI can produce an insightful piece. I rely mostly on HN to tell them apart value-wise.

Re: Everything as code: How we manage our company in one monorepo

#100

Post by talos »

lawrjone wrote: post #98
talos wrote: post #92

Earlier quoted context omitted.

Yeah it reads like it, and if a random AI detector (GPTZero) is to be believed it's pretty much all AI generated. Crazy that nobody can be bothered to get rid of the obvious AI-isms "This isn't just for...", "The Challenges (And How We Handle Them)", "One PR. One review. One merge. Everything ships together." It's an immediate signal that whoever wrote this DGAF.

I hadn't come across GPTZero before and wondered if it worked. Just testing on a sample of my blog posts (I do one each year) I got a 100% AI generated mark for a post in... 2022, and 2023. Both before AI tools were around. Not to say this post isn't AI generated but you might want a better tool (if one exists)

Yeah, it's got a real issue with false positives. And I've tried a bunch of other tools (Sapling, ZeroGPT, a few others) and actually GPTZero was the best of the bunch. The others would miss obviously AI generated content that I'd just generated to test them.

I've had a blog post kicking around about this for a while, it's CRAZY how much more expensive AI detection is than AI generation.

In my mind content generated today with AI "tells" like the above and a general zero-calorie-feel that also trip an AI detector are very likely AI generated.

Post reply on HN