[alphapug68]

I have experimented with a local setup in our team.

With the new Docker compose watch functionality I think it works well.

https://docs.docker.com/compose/how-tos/file-watch/

For me this has negated the need for manual mounting.

I combine the above with dotnet watch —-non-interactive in the dockerfile for dotnet and a simple ng serve in our Angular apps.

If new dependencies are added via npm install you can set it so that Docker watch will auto rebuild your container. So it gets around that issue too.

I have a .bat file in our repo that runs the Docker compose action to start up all the needed services and has some powershell to wait until the main UI service is up. When it’s up it auto opens the web browser.

I have a docker container that uses Dozzle (https://dozzle.dev/) for log monitoring across the various services. It can also stop/restart containers if needed.

I also have a container that can be ran to perform a database restore from an external Postgres DB into a local Postgres Docker container.

I will say that dotnet debugging is clunky. You can attach to the Docker container in Visual Studio but if a hot reload has happened you can’t debug again until the app has restarted. For dotnet if I need to do some intensive debugging I tend to spin it up outside Docker for this reason.

[hiatus]

> This negates the need for manual mounting.

The documentation you linked says it is a complement not a replacement.

> Compose supports sharing a host directory inside service containers. Watch mode does not replace this functionality but exists as a companion specifically suited to developing in containers.

[alphapug68]

I haven’t had the need to mount anything manually for local development. It entirely replaces it for my needs. This is for a stack using some Postgres databases, dotnet, react, node.js and angular.