Trying to start out w/ DevContainer and LiveReload

Hi all, just starting out w/ Phoenix using VSCode + DevContainer. I’ve tried some basic hello world to try out the live reload (eg changing some simple text on a page) but it doesn’t seem to work as simply as I thought it would.

Steps to reproduce:

  1. Pulled the Phoenix 1.6.2 + Elixir + Postgres devContainer from here: vscode-dev-containers/containers/elixir-phoenix-postgres at main · microsoft/vscode-dev-containers · GitHub. Copied the .devContainer into an arbitrary folder on my local drive.

  2. Opened code inside WSL VSCode.

  3. Followed sample Hello World sample startup from here: Up and Running — Phoenix v1.6.2

  4. I got the site to load on localhost:4000, through mix phx.server. Traffic routes from my Windows 10 host to the docker container > phoenix server. Page loads fine.

  5. I try to modify and saved something inside lib/hello/templates/page/index.html.heex.

At this point I expected any change to reflect back to the browser w/o need for refresh. It doesn’t. There are no errors reported in the elixer console, nor on my Chrome browser Dev toolbox; there is some warning about “Some cookies are misusing the recommended “SameSite“ attribute”, but I assume that’s unrelated.

If I hit F5 on the browser, I then notice the terminal shows Compiling 1 file, and the file w/ the refreshed content shows up now.

Any help/pointer to help me in the right direction would be appreciated. The few tutorial I followed online seemed to indicate hot reload was available out of the box? Is there a tutorial someone has used for building a phoenix devContainer that has better luck than me (really don’t like installing numerous toolboxes on my host machine)?


You are probably running into this bug in WSL: [WSL2] File changes made by Windows apps on Windows filesystem don't trigger notifications for Linux apps · Issue #4739 · microsoft/WSL · GitHub

If your repo is stored in the Windows filesystem, then programs running in WSL (such as mix) will not received file change notifications. If you copy the folder to the WSL file system, live reload should start working. E.g. in a WSL bash shell:
$ cp -r /mnt/c/projects/hello_world ~/hello_world

To open the project in VSCode, first remote to WSL and open the folder, then use the ‘Reopen in container’ command.

Krendil, that definitely explains it. Is there by chance a best practice on how most people are using devcontainer (or just bare docker) to jumpstart dev (and not need to focus on the setup so much)? I’ll have to dig some more this weekend to figure out a setup that would be clean and easy to jumpstart.


An easier way to get started might be to use the “Remote-Containers: Clone Repository in Container Volume…” to do the initial clone of the repo. This clones the repo directly into a docker volume in the WSL filesystem, but it does mean that you can only access the cloned files through VSCode and the devcontainer, and not through Windows Explorer.

The way I do it is to mount part of the WSL filesystem as a network share to a certain location in my Windows filesystem. The WSL filesystem is accessible as a network share with the path \\wsl$\<distro-name>\, e.g. \\wsl$\Ubuntu-20.04\. Using the mklink command in Windows, you can mount it to a folder location, e.g.

mklink /d C:\WSL-Projects\ \\wsl$\Ubuntu-20.04\home\krendil\projects\

This way, the files are conveniently accissible to Windows, while residing on the WSL filesystem. The downside is that this seems to break ssh-agent forwarding to the devcontainer. Unfortunately, I don’t have a solution to that.

1 Like