Docker Compose with .env overrides is very close to an ideal local dev environment, the only downside is if you don't use Linux you can hit some I/O bottlenecks (it got better with VirtioFS in Docker Desktop but still not native-speed)..

I still wait for properly usable remote work environment that trumps local in performance and convenience.... I feel like the VS Code approach with server-client IDE architecture and the client running as a web application is going in the right direction but not quite there yet.., Especially if you can leverage lots of RAM and GPU power in your workflow and often work from different locations, don't want to carry your laptop around but still want to use the same power, environment & configuration on any machine you work from....

How do you handle tooling? Install it in the parent or in the container? I quite like the idea of VS Code dev containers since it does a lot of the bootstrapping work to make the container be more like a full system, and I wish this “remote environment” idea was more widely supported amongst editors.

Hmm. By tooling are you referring to things like jq and other "uncommon" cli/tui apps I use to work against a code base locally? I think that's what you mean.

One of the best practices when using docker-compose to develop is actually to mount your code base as a volume. This lets you modify the code locally without requiring a complete rebuild of the container each time code is modified.

You might have to no-hup a service or run it not as pid1 (init container or supervisord) so it can restart without killing the container but that depends on the work being done.

I'm trying to find a good example to show you but I'm not finding much. If you have a medium account this might be decent, I don't have one but it starts off going through the process https://medium.com/swlh/tutorial-how-to-use-docker-volumes-t...

With that said I use literally the exact same containers that are pushed to production.

Mostly tools that you are going to run during the development process that aren’t going to be run in CI/at “build time”. So sure, possibly jq, but especially language server and editor integrations. Do you run the editor in the container? Do not use these tools?

Devcontainers are indeed the answer if you’re using VSC. I use the docker-outside-docker feature (there’s a few flavors of these) so my app can be defined with docker-compose. The experience is nice once you’ve taken the time to customize your image, settings, and extensions.