Stripe's Monorepo Developer Environment

My small team uses devenv for all our development environments and we really like it. Local DX is really important to me and to our team, which is a big part of why we've chosen Nix and devenv.

As we've started to use it more extensively, we've also found that we want to add some enhancements, work out some bugs, and experiment with our own customizations out-of-tree, etc. I'm happy to report here on HN that devenv is well-documented and easy to extend for Nix users who have some experience with Nix module systems, and that Domen is really responsive to PRs. :)

Containers are a great deployment target, but they're not really a great development environment for a few reasons (e.g., they're Linux-specific, so they require extra virtualization on non-Linux operating systems, the kind of isolation they provide is more of a hindrance than a help when it comes to working on your local filesystem, and for them to be useful you have to set up infrastructure to push and pull your private containers to and from).

Nix is a better fit for this, and when you're using Nix you can also have Nix generated containers for deployment. I think you can also use a container with Nix in to provide the devcontainers interface to devs who don't have Nix installed locally, and have it in turn use Nix against your project's flake to set up its environment.

> When I read about nix, reproducibility is a goal, but [...] isolation is a non-goal.

Generally, yes.

But you can use or put together something like this to run Nix inside a devcontainer instead of locally: https://github.com/xtruder/nix-devcontainer

So you can use them in conjunction (or alternation, if for some projects you're okay running without a container) without having to specify your development environments twice.

> 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).

There are basically two kinds of integration you can do for a project with Nix, which I'll call deep and shallow. In shallow integration, you just have Nix provide the toolchain and then you build the project (manually, with a script, with a Makefile, whatever). This is pretty common and pretty easy, and gives you no protection from malicious NPM build scripts.

For deep integration, you can actually have Nix build your whole project. This has some downsides, like that it can't really handle incremental builds. It also imposes restrictions, like no network access by anything but Nix at build time, all packages are built by special build users with no homedirs and no perms to access anything, etc. When you do that kind of build/install, you do get some protection from crypto miners lurking in the NPM registry or PyPI or whatever.

Very insightful blog post!

> Finally: the development experience, of course, is only part of the story: the full lifecycle of code and features continues onward into CI and code review and ultimately through deployment into production, where it will be further observed, debugged, and evolved. Writing about those systems would require further posts at least this long.

In case the author is around: I would love to read those!

It’s $250/month for a c6g 2xl 1tb ebs on demand pricing go reserved instances. Given they use AWS and are a major customer, you can expect excellent pricing above the above public pricing quote.

Considering the cost of a developers time, and you can do shenanigans to drive that even lower, this all feels totally reasonable.