Stop rebuilding your Docker image after every front-end change

I joined a project where the Vue front end ran in its own container, but the docker-compose.yml had no bind mount for the source code. Instead, the Dockerfile copied the project in and ran npm install at build time, so the image was completely self-contained.

But this also means that changes to code require you to rebuild the image to load the new source code. That is a terrible dev experience.

The natural response would be to use a bind mount into the container instead, but this team had their own specific reasons for not wanting to do that. As a new dev on the team, instead of trying to fight that battle, I instead looked to see if there was a different solution to the poor developer experience.

I could have added a bind mount in a docker-compose.override.yml just for myself, and that would have worked for source changes. But it wouldn't do anything when a dependency changed, and I'd rather fix the workflow for the whole team than keep a private tweak on my machine.

Reading through the docs, I found that Docker Compose has a watch feature that fixes this without needing to introduce a bind mount. You describe which paths to watch and what to do when they change, right in the compose file.

# docker-compose.yml
services:
  frontend:
    build: .
    develop:
      watch:
        - action: sync
          path: ./src
          target: /app/src
        - action: rebuild
          path: package.json

Then start things with docker compose up --watch instead of plain up.

The sync action copies changed files into the running container, so the dev server's hot reload picks them up just like it would with a bind mount.

The rebuild action does a full image rebuild, but only when package.json changes, since a new dependency needs npm install to run again and sync can't do that.

There are other actions available as well. As always, read the docs for full details.

This change got me the normal developer workflow I was used to, without requiring me to force the team to change how their project was structured.

Here to help,

Joel

P.S. If you'd like someone to join your project who doesn't just ship features, but also makes the developer experience better for the whole team, let's talk.