[kevmo314]

I use them as a last resort. They're nice in theory but you'll lose your extensions (which you can configure but if you check it in you're imposing on everyone else...), bash history, and most debugging tools you have installed locally. Unfortunately, those are really "features" of being in a container and if you work around them it's kind of defeating the point of a container.

They're helpful for cross-architecture debugging and serving as a source of truth that the build actually works on a dev machine but definitely the ergonomics leave a bit to be desired.

[tom_]

If you don't get to pick your own extensions, does that mean you also don't get to pick your own keyboard shortcuts, font and colour scheme?! That would be a wider interpretation of "cattle, not pets" than I am used to...

[kevmo314]

Those are configured on the client so luckily you get to keep them. Extensions in VS Code are a bit different because some (many?) run on the host and as a result devcontainers wipe them out.

I do agree though, I think devcontainers are in an awkward spot where they're cattle but my IDE/environment is typically a pet...

[sunaookami]

Nix with direnv is better for something like this but it obviously won't work on Windows.