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

We shrunk our Javascript monorepo git size

jonathancreamer.com

Post reply on HN
Print view View original

171–180 of 226 posts

Re: We shrunk our Javascript monorepo git size

#171

Post by dijit »

wbl wrote: post #169
dijit wrote: post #160

Earlier quoted context omitted.

Ok, examples: * SMTP * Kerberos (there was a time you could use KRB4 with Windows because AD is just krb4 with extensions: now you have to use AD). * HTML (activex etc) * CALDAV // CARDDAV * Javas portability breakage * MSN and AOL compatibility. “oh, but its not the same ”. It never is, which is why I didnt want to give examples and preferred you speak to someone who knows the history more than a tiny internet comme…

You understand in these cases the issue was not contributing back right?

Yeah… that was the issue.

Re: We shrunk our Javascript monorepo git size

#174

Post by crazygringo »

smashedtoatoms wrote: post #150
develatio wrote: post #136

Earlier quoted context omitted.

Can’t we split the packages into logical groups and maybe have 20 or 30 monorepos of 70-100 packages? I doubt that all the devs involved in that monorepo have to deal with all the 2500 packages. And I doubt that there is a circular dependency that requires all of these packages to be managed in a single monorepo.

People act like managing lots of git repos is hard, then run into monorepo problems requiring them to fix esoteric bugs in C that have been in git for a decade, all while still arguing monorepos are easy and great and managing multiple repos is complicated and hard. It's like hammering a nail through your hand, and then buying a different hammer with a softer handle to make it hurt less.

> all while still arguing monorepos are easy and great

I don't know anyone who says monorepos are easy.

To the contrary, the tooling is precisely the hard part.

But the point is that the difficulty of the tooling is a lot less than the difficulty of managing compatibility conflicts between tons of separate repos.

Each esoteric bug in C only needs to be fixed once. Whereas your version compatibility conflict this week is going to be followed by another one next week.

Re: We shrunk our Javascript monorepo git size

#175

Post by szundi »

wbl wrote: post #169
dijit wrote: post #160

Earlier quoted context omitted.

Ok, examples: * SMTP * Kerberos (there was a time you could use KRB4 with Windows because AD is just krb4 with extensions: now you have to use AD). * HTML (activex etc) * CALDAV // CARDDAV * Javas portability breakage * MSN and AOL compatibility. “oh, but its not the same ”. It never is, which is why I didnt want to give examples and preferred you speak to someone who knows the history more than a tiny internet comme…

You understand in these cases the issue was not contributing back right?

Part of the game

Re: We shrunk our Javascript monorepo git size

#176

Post by szundi »

clktmr wrote: post #76
tux3 wrote: post #32

For those wondering where this new git-survey command is, it's actually not in git.git yet! The author is using microsoft's git fork, they've added this new command just this summer: https://github.com/microsoft/git/pull/667

[flagged]

This comment is downvoted, however you can be sure that managers in these corporations make these decisions deliberately - like half the time.

I find these insightful reminders. Use the vanilla free versions if the difference is negligeble.

Re: We shrunk our Javascript monorepo git size

#177

Post by DeathMetal3000 »

EDEdDNEdDYFaN wrote: post #112

better question - does the changelog need to be checked in the first place?

They fixed a bug on a tool that is widely used. In what world is questioning why an organization is checking in a file that you have no context on a “better question”.

Re: We shrunk our Javascript monorepo git size

#178

Post by cjpearson »

lbriner wrote: post #110
IshKebab wrote: post #84

Earlier quoted context omitted.

I thought Microsoft had one monorepo. Isn't that kind of the point? How many do they have?

The point of a monorepo is that all the dependencies for a suite of related products are all in a single repo, not that everything your company produces is in a single repo.

Most people use the "suite of related products" definition of monorepo, but some companies like Google and Meta have a single company-wide repository. It's unfortunate that the two distinct strategies have the same name.

Re: We shrunk our Javascript monorepo git size

#179

Post by sshine »

tazjin wrote: post #162
sshine wrote: post #145

Earlier quoted context omitted.

> I'm surprised they are actually using Azure DevOps internally. Creating your own hell I guess. Even the hounds of hell may benefit from dogfooding.

houndfooding?

Ain't nothing but a hound dog.

Re: We shrunk our Javascript monorepo git size

#180

Post by HdS84 »

crazygringo wrote: post #174
smashedtoatoms wrote: post #150

Earlier quoted context omitted.

People act like managing lots of git repos is hard, then run into monorepo problems requiring them to fix esoteric bugs in C that have been in git for a decade, all while still arguing monorepos are easy and great and managing multiple repos is complicated and hard. It's like hammering a nail through your hand, and then buying a different hammer with a softer handle to make it hurt less.

> all while still arguing monorepos are easy and great I don't know anyone who says monorepos are easy. To the contrary, the tooling is precisely the hard part. But the point is that the difficulty of the tooling is a lot less than the difficulty of managing compatibility conflicts between tons of separate repos. Each esoteric bug in C only needs to be fixed once. Whereas your version compatibility conflict this week…

Thad exactly the problem. At least tooling can solve mono repo problems. But commits , which should span multiple repos, have no tooling at all. Except pain. Lots of pain.
Post reply on HN