Docker Compose Develop Watch and Syncing Files from the Host Container to a Service

This thread has helped me better understand the "develop" behavior with Docker Compose

The Docker Compose documentation of "Example 1" in "Use Compose Watch" does a pretty good job explaining things. Perhaps part of it should be added to the Compose File - Develop page instead of hidden by links?

After the service is up, the watch mode starts monitoring the target directories and files. Then, whenever a source file in the web/ directory is changed, Compose syncs the file to the corresponding location under /src/web inside the container. For example, ./web/App.jsx is copied to /src/web/App.jsx.

Once copied, the bundler updates the running application without a restart.

Unlike source code files, adding a new dependency can’t be done on-the-fly, so whenever package.json is changed, Compose rebuilds the image and recreates the web service container.

The "Rebuild Everything" Method

This appears to be the ideal process:

1. build the image with the current state of files copied into it run compose with watch
2. whenever a file changes, rebuild the image so it has the updated state of files within it

The "Sync Files Manually" Approach

Alternatively, outside of Docker Compose for syncing files (and based on the suggestions in the thread):

1. build the image with the current state of files copied into it (use a "watch" or "reload" command built into whatever app you're running)
2. run compose (do not use develop or watch)
3. run docker compose cp ./src app:/src this should trigger the watch/reload command within the container

The "Volume Mounting" Method

Another option is to build a base image that does not include source code and only builds an environment in which the source code can be built or run. Then, a volume can be mounted into the container with the latest source code from the host environment, and the code can be run.

Something like this:

1. build the image with the environment
2. run compose with a volume mounted
3. run the steps in the container to build/run the source

It all depends on your developer workflow and what is understandable and can be used daily with minimal disruption to the developer feedback loop.

Things to consider:

• how often are dependencies changing? should they be re-installed within the container or should the image be rebuilt (since one of the steps is installing dependencies)?
• is there a "watch" or "reload" command that reloads your app based on files changes?
• how much time does it take to rebuild the image? is it acceptable to yourself and to your team to wait for a rebuild on every set of source code changes? does it slow the developer feedback loop too much?