Yet another replay of timesharing development experiences, I guess we need a couple of generations more to count how many times does a pendulum swing back and forth during a developer's lifetime.
Stripe's Monorepo Developer Environment
31–40 of 249 posts
Re: Stripe's Monorepo Developer Environment
#32They 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.
The article mentions that the LSP itself already has baked-in support to enable editors to send chunks of unsaved edits to the language server (LS) as they happen.
What Stripe’s configuration introduced is that they used a remote LS instead of the default local LS. Regardless, VS Code already defers LSP communication until it feels idle, and developers are used to that. So I wouldn’t expect a remote LS to significantly impact the level of inconsistency that developers already accept when using a local LS.
Re: Stripe's Monorepo Developer Environment
#33This 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.
understated -> overstated
Re: Stripe's Monorepo Developer Environment
#34This 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.
Just because some successful companies use some approach doesn't make it the best practice. I have seen firsthand nuisance of monorepo, which took almost 15minutes to correctly switch branches on intel machines(and decently spiked the CPU by causing windows defender to panic). It has decent benefit of easy code sharing, but build and test are soul sucking experiences and if someone decides to run some updated formatter and linter rule accidentally, the whole MR becomes a nightmare to correctly review(once had a 2k+ changes and had to request to rollback and then only commit what they actually wanted to change).
Re: Stripe's Monorepo Developer Environment
#35Earlier quoted context omitted.
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.
FYI, I've helped set up StableBuild (https://www.stablebuild.com) to help pin stuff in Docker that's normally virtually impossible to pin (e.g. OS package repos, Docker base images, random files from the internet, etc.)
Re: Stripe's Monorepo Developer Environment
#36Earlier quoted context omitted.
> 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.
In addition to what you mentioned, the ability to atomically commit to a library and all of its consumers. And for a change to a library run the tests of all of its consumers as well.
Re: Stripe's Monorepo Developer Environment
#37Earlier quoted context omitted.
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
This blog post says 2 and a half minutes not seconds.
I know Bazel is a build system which distributes builds among remote machines.
In fact using any computer language you can achieve these goals - you just need to program it.
So yes you could probably do all the things with all the things, but Basel does not solve this problem out of the box.
I wonder why stripe didn’t “just use Bazel”.
Re: Stripe's Monorepo Developer Environment
#38I chatted to Nelson when I was designing brisk ( https://github.com/brisktest/brisk ) and his insight informed the development of it. Among other things, Brisk allows you to run tests for your local code changes in the cloud (basically the pay mini test piece but for any test runner) We also have a sync step much like the one described here and allow users to run one off commands (linters, tsc etc)
> Brisk allows you to run tests for your local code changes in the cloud
how does this work for interactive debugging?
I was going to ask the same about the system in TFA but I might as well ask you :)
Re: Stripe's Monorepo Developer Environment
#39Does Stripe use RoR?
The author mentions the codebase was Ruby, but I didn't see if they talked about Rails.
Re: Stripe's Monorepo Developer Environment
#40Earlier quoted context omitted.
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
This blog post says 2 and a half minutes not seconds. I know Bazel is a build system which distributes builds among remote machines. In fact using any computer language you can achieve these goals - you just need to program it. So yes you could probably do all the things with all the things, but Basel does not solve this problem out of the box. I wonder why stripe didn’t “just use Bazel”.
> This blog post says 2 and a half minutes not seconds.
It's meaningless to say "we can run tests in seconds". You can't run my tests in seconds because they're single threaded and take 10 minutes. The important thing is the speedup, and they got a pretty good speedup. Arguably the nop build/test time is important too but it doesn't look like they measured that.
> Basel does not solve this problem out of the box.
Yes it does.
> I wonder why stripe didn’t “just use Bazel”.
In my experience it's because setting up Bazel is a) more work than setting up some ad-hoc build system (Make or CMake or whatever) and b) difficult to switch to retrospectively. So it only gets used where you have people who are experienced enough to know that you will wish you had started with it, and can convince the inexperienced people that it's worth the effort.
Usually you get too many inexperienced people saying "it's too difficult; we'll be fine with Make".