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

11–20 of 249 posts

Re: Stripe's Monorepo Developer Environment

#11

Post by reillys »

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)

To be clear the sync step is used for the test suite execution not only the one off command running - it’s just something we can also easily do because we have a hot env in the cloud

Re: Stripe's Monorepo Developer Environment

#13

Post by dirtbag__dad »

stavros wrote: post #9
domenkozar wrote: post #2

We've been building https://devenv.sh for that reason, I expect more companies to go back to local development once they see DX has improved locally.

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?

Re: Stripe's Monorepo Developer Environment

#14

Post by rvz »

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 large your code base is.

Re: Stripe's Monorepo Developer Environment

#15

Post by pavlov »

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…

Meta also has a massive monorepo accessed primarily through cloud devservers.

When several of the world’s most successful software companies use this approach, it’s hard to argue that it’s inherently bad. Of course it’s sensible to discuss what lessons apply to smaller companies who don’t have the luxury of dedicated tooling teams supporting the monorepo and dev environment.

Re: Stripe's Monorepo Developer Environment

#16

Post by Aeolun »

They decided to keep the code on the local machine, but the language server on the remote one. That seems like a recipe for inconsistency. You only get relevant results from your language server once your code has synced.

Re: Stripe's Monorepo Developer Environment

#17

Post by ABS »

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…

very much recommended practice by many with, of course, caveats and situations where perfect is the enemy of good, etc, etc

e.g. https://trunkbaseddevelopment.com/monorepos/

Re: Stripe's Monorepo Developer Environment

#18

Post by joshuamorton »

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.

This is one of the biggest selling points of bazel-like build systems. Like to the extent that, for some changes, bazel can say "even though you changed this source file, I can be 100% certain that that change didn't affect any tests and so I will not run them"

Re: Stripe's Monorepo Developer Environment

#19

Post by Maxious »

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)

I'd suggest you revise your competitor analysis. Bazel definitely has a test command that with remote execution and caching absolutely allows you to run entire test suites in seconds* both locally and in CI eg. https://blog.aspect.build/typescript-with-rbe

Re: Stripe's Monorepo Developer Environment

#20

Post by azthecx »

spacemonkey92 wrote: post #12
KolmogorovComp wrote: post #4

> In addition, Stripe’s monorepo was (to our knowledge) the largest Ruby codebase in existence Bigger than shoppify's?

I also wonder how they handle merge requests in a monorepo, especially when it comes to the code review process.

Typically you have owner files or similar in the subprojects that are read by automation tooling and humans alike
Post reply on HN