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

Stripe's Monorepo Developer Environment

blog.nelhage.com

Post reply on HN
Print view View original

21–30 of 249 posts

Re: Stripe's Monorepo Developer Environment

#21

Post by lijok »

rvz wrote: post #14

This isn't recommended practice really and there is nothing about this which justifies having to maintain huge code bases in a single folder or multiple folders in one larger one. Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes. Sounds like an emergence of a new bad practice if you are having to praise how…

> Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes.

No different to having thousands of smaller repos instead.

I personally dislike monorepos, for very niche, in-the-weeds operational reasons (as an infra person), but their ergonomics for DX cannot be understated.

Re: Stripe's Monorepo Developer Environment

#22

Post by __jonas »

lijok wrote: post #21
rvz wrote: post #14

This isn't recommended practice really and there is nothing about this which justifies having to maintain huge code bases in a single folder or multiple folders in one larger one. Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes. Sounds like an emergence of a new bad practice if you are having to praise how…

> Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes. No different to having thousands of smaller repos instead. I personally dislike monorepos, for very niche, in-the-weeds operational reasons (as an infra person), but their ergonomics for DX cannot be understated.

The 'ergonomics for DX' benefit is that you can share code across projects without having to go down the path of creating a package / library pushed to some internal registry and pulled by each project right?

Or are there any other aspects to the monorepo architecture that make it beneficial for large companies like that?

Just curious, I've never worked in such an environment myself.

Re: Stripe's Monorepo Developer Environment

#23

Post by papruapap »

rvz wrote: post #14

This isn't recommended practice really and there is nothing about this which justifies having to maintain huge code bases in a single folder or multiple folders in one larger one. Won't be surprised to see that many would probably need a safari map or README documentation in every single folder to navigate a repository as large as stripes. Sounds like an emergence of a new bad practice if you are having to praise how…

imo monorepos are great, but the tooling is not there, especially the open-sourced ones. Most companies using monorepos have their own tailored tools for it.

Re: Stripe's Monorepo Developer Environment

#25

Post by srvaroa »

"This scale – the scale of devprod, and in turn the scale of the overall organization, such that it could afford 10 FTEs on tooling – was a major factor in our choices"

Is basically the summary for most mono/multi repo discussions, and a bunch of other related ones.

Re: Stripe's Monorepo Developer Environment

#26

Post by tmerse »

drakerossman wrote: post #7
evnix wrote: post #5

Earlier quoted context omitted.

How is this better or different from tools like dev which use docker

It (obviously) leverages Nix, which in turn means the environment is declarative and fully reproducible (not "reproducible" as in docker). Now, you can use just Nix's devShells, but with devenv you have a middleground between just Nix package manager and a full fledged NixOS module system. Basically, write out one line of code - and you've got your Postgres, another one - full linter set up for whatever language you'…

Can I also get the security/isolation benefits that a duly configured docker/podman can provide (container can only act on mounted volume, non-root user, other seccomp settings?).

I feel better doing my "npm install"s in such an environment (of course it's still not a VM – but that's another topic).

When I read about nix, reproducibility is a goal, but security/isolation is a non-goal.

Re: Stripe's Monorepo Developer Environment

#28

Post by stavros »

dirtbag__dad wrote: post #13
stavros wrote: post #9

Earlier quoted context omitted.

Nix is the right tool for this, developing a tool to make Nix's UX easier is a great idea. Thanks for this!

What about dev containers?

You mean Docker? They tend to rot much more than I'd like, mostly because you forget to pin something at some point. With Nix, you can't forget.

Re: Stripe's Monorepo Developer Environment

#29

Post by delhanty »

>Some caveats: It’s been nearly five years, and I have no doubt that I have misremembered some of the specific details, even though I’m confident in the overall picture. I’m also certain that Stripe has continued evolving and I make no claim this document represents the developer experience at Stripe as of today.

Are there any more recently ex-Stripe folks here willing and able to comment on how Stripe's developer environment might have evolved since the OP left in 2019?

Re: Stripe's Monorepo Developer Environment

#30

Post by IshKebab »

reillys wrote: post #10
IshKebab wrote: post #6

Earlier quoted context omitted.

Can't you achieve all that just using a build system with reliable remote builds & caching e.g. Bazel, Buck, Please, etc? That also avoids hacky sync scripts.

No you can’t. They don’t work from your local development env and also work in your CI env. Mostly Brisk was designed to run your complete test suite on every codes save (ie local save) but it also works great from your CI. We can run entire test suites in seconds which is performance you don’t get with those systems you named (which are generally for building/compiling)

> They don’t work from your local development env and also work in your CI env.

Err yes they do? Unless you mean something really specific that I'm not getting?

Post reply on HN