> However, in the past few years, I have reverted away from shortcuts and sometimes letting developers sweat the details — or I document them in-depth.

Yes, me too! That’s why you can find hours of my writing online about the topics, including a 21 day email course that covers volumes, networking, and running Swarm in production.

> You need to use a named volume like this

Thanks for the suggestion, but this actually would make the entire example not work. I’d agree to disagree but I think it would cause confusion.

The local directory being shared in the builder container and the running container, which are using the same image, is what makes the entire example work. Adding a named volume as you suggested would indeed make it more isolated… in a way that would not allow the running container to access it.

If you really want a named volume you’d have to create it externally, and then reference it from both docker-compose files using external: true which means it’d need to be on the same network to be discoverable, meaning you’d also need to create a network externally and reference it from both docker-compose files as well.

> Additionally I recommend adding a .dockerignore file in the project to ignore node_modules.

That would do nothing in the case of using other Dockerfiles. The only time .dockerignore is used is when creating the context for a docker build. Seems how there is not a custom Dockerfile or docker build at this point, .dockerignore wouldn’t affect anything in this example.

I write more about production ready Dockerfiles and cover using .dockerignore’s here in a later section of this series: https://hackernoon.com/a-tale-of-two-docker-multi-stage-build-layers-85348a409c84