HTML templates reloading issue (TailwindCSS)

[adrivn]

Hello Nick,

First off, thank you loads for the work you put into this bundle, you have inspired me greatly to dive into Docker and containerization.

• System: W10, running everything under WSL2, so no mounting issues at all.

The issue at hand relates to hot reloading while developing. I find that whenever I modify a *.py file the webapp reloads just fine, showing the changes instantaneously. This is not the case when its an *.html template being modified. The css and js watchers are up and running. I checked the tailwind.config.js file and its pointing to the app folder, recursively and gathering all *.html files, so I don't know where to look now.

Thank you

[nickjj]

Hi,

The HTML files would still be related to Django btw, it would be really interesting if py files worked but html didn't.

Do the CSS and JS watchers show that files were updated when you make a change by notifying you in the terminal? It should say it was rebuilt.

[adrivn]

Do the CSS and JS watchers show that files were updated when you make a change by notifying you in the terminal? It should say it was rebuilt.

No, upon saving/modifying an HTML file it does not show up on the log "Rebuilding... Done in XXXms".

However when I modify a Python file (views.py let's say) it does reload/update, logging this to the console:

[hellodjango-web-1 | [2022-11-04 14:42:05 +0000] [8] [INFO] Worker reloading: /app/src/pages/views.py modified
hellodjango-web-1 | [2022-11-04 14:42:05 +0000] [8] [INFO] Worker exiting (pid: 8)

This is the log upon starting the container:

[+] Running 6/0
⠿ Container hellodjango-css-1 Created 0.0s
⠿ Container hellodjango-js-1 Created 0.0s
⠿ Container hellodjango-redis-1 Created 0.0s
⠿ Container hellodjango-postgres-1 Created 0.0s
⠿ Container hellodjango-worker-1 Created 0.0s
⠿ Container hellodjango-web-1 Created 0.0s
Attaching to hellodjango-css-1, hellodjango-js-1, hellodjango-postgres-1, hellodjango-redis-1, hellodjango-web-1, hellodjango-worker-1
hellodjango-postgres-1 |
hellodjango-postgres-1 | PostgreSQL Database directory appears to contain a database; Skipping initialization
hellodjango-postgres-1 |
hellodjango-postgres-1 | 2022-11-04 14:09:30.598 UTC [1] LOG: starting PostgreSQL 15.0 (Debian 15.0-1.pgdg110+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 10.2.1-6) 10.2.1 20210110, 64-bit
hellodjango-postgres-1 | 2022-11-04 14:09:30.602 UTC [1] LOG: listening on IPv4 address "0.0.0.0", port 5432
hellodjango-postgres-1 | 2022-11-04 14:09:30.602 UTC [1] LOG: listening on IPv6 address "::", port 5432
hellodjango-redis-1 | 1:C 04 Nov 2022 14:09:30.615 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
hellodjango-redis-1 | 1:C 04 Nov 2022 14:09:30.615 # Redis version=7.0.5, bits=64, commit=00000000, modified=0, pid=1, just started
hellodjango-redis-1 | 1:C 04 Nov 2022 14:09:30.615 # Warning: no config file specified, using the default config. In order to specify a config file use redis-server /path/to/redis.conf
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.616 * monotonic clock: POSIX clock_gettime
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.625 * Running mode=standalone, port=6379.
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.626 # Server initialized
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.626 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * Loading RDB produced by version 7.0.5
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * RDB age 135642 seconds
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * RDB memory usage when created 1.18 Mb
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * Done loading RDB, keys loaded: 1, keys expired: 0.
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * DB loaded from disk: 0.002 seconds
hellodjango-redis-1 | 1:M 04 Nov 2022 14:09:30.628 * Ready to accept connections
hellodjango-postgres-1 | 2022-11-04 14:09:30.631 UTC [1] LOG: listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
hellodjango-postgres-1 | 2022-11-04 14:09:30.719 UTC [27] LOG: database system was shut down at 2022-11-03 00:28:48 UTC
hellodjango-postgres-1 | 2022-11-04 14:09:30.904 UTC [1] LOG: database system is ready to accept connections
hellodjango-web-1 | [2022-11-04 14:09:34 +0000] [1] [INFO] Starting gunicorn 20.1.0
hellodjango-web-1 | [2022-11-04 14:09:34 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
hellodjango-web-1 | [2022-11-04 14:09:34 +0000] [1] [INFO] Using worker: sync
hellodjango-web-1 | [2022-11-04 14:09:34 +0000] [8] [INFO] Booting worker with pid: 8
hellodjango-css-1 |
hellodjango-css-1 | Rebuilding...
hellodjango-css-1 |
hellodjango-css-1 | Done in 622ms.
hellodjango-worker-1 |
hellodjango-worker-1 | -------------- celery@6d7987657838 v5.2.7 (dawn-chorus)
hellodjango-worker-1 | --- ***** -----
hellodjango-worker-1 | -- ******* ---- Linux-5.10.102.1-microsoft-standard-WSL2-x86_64-with-glibc2.31 2022-11-04 14:09:35
hellodjango-worker-1 | - *** --- * ---
hellodjango-worker-1 | - ** ---------- [config]
hellodjango-worker-1 | - ** ---------- .> app: hello:0x7f5fcde6b2d0
hellodjango-worker-1 | - ** ---------- .> transport: redis://redis:6379/0
hellodjango-worker-1 | - ** ---------- .> results: redis://redis:6379/0
hellodjango-worker-1 | - *** --- * --- .> concurrency: 4 (prefork)
hellodjango-worker-1 | -- ******* ---- .> task events: OFF (enable -E to monitor tasks in this worker)
hellodjango-worker-1 | --- ***** -----
hellodjango-worker-1 | -------------- [queues]
hellodjango-worker-1 | .> celery exchange=celery(direct) key=celery
hellodjango-worker-1 |
hellodjango-worker-1 |
hellodjango-worker-1 | [tasks]
hellodjango-worker-1 |
hellodjango-worker-1 |
hellodjango-worker-1 | [2022-11-04 14:09:35,825: INFO/MainProcess] Connected to redis://redis:6379/0
hellodjango-worker-1 | [2022-11-04 14:09:35,831: INFO/MainProcess] mingle: searching for neighbors
hellodjango-worker-1 | [2022-11-04 14:09:36,849: INFO/MainProcess] mingle: all alone
hellodjango-worker-1 | [2022-11-04 14:09:36,884: WARNING/MainProcess] /home/python/.local/lib/python3.11/site-packages/celery/fixups/django.py:203: UserWarning: Using settings.DEBUG leads to a memory
hellodjango-worker-1 | leak, never use this setting in production environments!
hellodjango-worker-1 | warnings.warn('''Using settings.DEBUG leads to a memory
hellodjango-worker-1 |
hellodjango-worker-1 | [2022-11-04 14:09:36,885: INFO/MainProcess] celery@6d7987657838 ready.
hellodjango-postgres-1 | 2022-11-04 14:14:30.750 UTC [25] LOG: checkpoint starting: time
hellodjango-postgres-1 | 2022-11-04 14:14:31.098 UTC [25] LOG: checkpoint complete: wrote 6 buffers
hellodjango-web-1 | [2022-11-04 14:42:06 +0000] [60] [INFO] Booting worker with pid: 60

[nickjj]

No, upon saving/modifying an HTML file it does not show up on the log "Rebuilding... Done in XXXms".

Have you tried visiting the page and reloading? It might not show up in the terminal but it should update.

The CSS looks like it's reloading based on this:

hellodjango-css-1 |
hellodjango-css-1 | Rebuilding...
hellodjango-css-1 |
hellodjango-css-1 | Done in 622ms.

Have you tried doing a hard reload in your browser to clear any cache?

[adrivn]

Have you tried visiting the page and reloading? It might not show up in the terminal but it should update.

I visited and reloaded after each modification and save. Not working.

The CSS looks like it's reloading based on this:

Yes, the worker starts up fine and does the first build just fine, but not subsequent.

Have you tried doing a hard reload in your browser to clear any cache?

Just tried, same result (no HTML/CSS update)

[nickjj]

Is your source code living inside of WSL 2's file system or is it mounted from a drive in Windows?

I would say try putting it inside of WSL 2's file system, not only may it fix this issue but it's also going to be way way faster. This is how I run things too for reference.

[adrivn]

It is living and running from inside the WSL2 system (I read you recommend it in a different closed issue), it doesn't seem to help with the non-reload of the CSS:

[nickjj]

Do you have DEBUG=true, NODE_ENV=development, WEB_RELOAD=true and DOCKER_WEB_VOLUME=.:/app in your .env file?

[adrivn]

Yes. All of those are identical in the .env file. For reference, here are the contents for the .env , docker-compose.yml and tailwind.config.js files

.env

# Default values are optimized for production to avoid having to configure
# much in production.
#
# However it should be easy to get going in development too. If you see an
# uncommented option that means it's either mandatory to set or it's being
# overwritten in development to make your life easier.

# Enable BuildKit by default:
#   https://docs.docker.com/develop/develop-images/build_enhancements
export DOCKER_BUILDKIT=1

# Rather than use the directory name, let's control the name of the project.
export COMPOSE_PROJECT_NAME=hellodjango

# In development we want all services to start but in production you don't
# need the asset watchers to run since assets get built into the image.
#
# You can even choose not to run postgres and redis in prod if you plan to use
# managed cloud services. Everything "just works", even optional depends_on!
#export COMPOSE_PROFILES=postgres,redis,web,worker
export COMPOSE_PROFILES=postgres,redis,assets,web,worker

# In development avoid writing out bytecode to __pycache__ directories.
#PYTHONDONTWRITEBYTECODE=
export PYTHONDONTWRITEBYTECODE=true

# You should generate a random string of 50+ characters for this value in prod.
# You can generate a secure secret by running: ./run secret
export SECRET_KEY=insecure_key_for_dev

# This should never be set to true in production but it should be enabled in dev.
#export DEBUG=false
export DEBUG=true

# Which Node environment is running? This should be "development" or "production".
#export NODE_ENV=production
export NODE_ENV=development

# A comma separated list of allowed hosts. In production this should be your
# domain name, such as "example.com,www.example.com" or ".example.com" to
# support both example.com and all sub-domains for your domain.
#
# This is being overwritten in development to support multiple Docker dev
# environments where you might be connecting over a local network IP address
# instead of localhost. You should not use "*" in production.
#export ALLOWED_HOSTS=".localhost,127.0.0.1,[::1]"
export ALLOWED_HOSTS="*"

# The bind port for gunicorn.
#
# Be warned that if you change this value you'll need to change 8000 in both
# your Dockerfile and in a few spots in docker-compose.yml due to the nature of
# how this value can be set (Docker Compose doesn't support nested ENV vars).
#export PORT=8000

# How many workers and threads should your app use? WEB_CONCURRENCY defaults
# to the server's CPU count * 2. That is a good starting point. In development
# it's a good idea to use 1 to avoid race conditions when debugging.
#export WEB_CONCURRENCY=
export WEB_CONCURRENCY=1
#export PYTHON_MAX_THREADS=1

# Do you want code reloading to work with the gunicorn app server?
#export WEB_RELOAD=false
export WEB_RELOAD=true

# You'll always want to set POSTGRES_USER and POSTGRES_PASSWORD since the
# postgres Docker image uses them for its default database user and password.
export POSTGRES_USER=hello
export POSTGRES_PASSWORD=password
#export POSTGRES_DB=hello
#export POSTGRES_HOST=postgres
#export POSTGRES_PORT=5432

# Connection string to Redis. This will be used for the cache back-end and for
# Celery. You can always split up your Redis servers later if needed.
#export REDIS_URL=redis://redis:6379/0

# You can choose between DEBUG, INFO, WARNING, ERROR, CRITICAL or FATAL.
# DEBUG tends to get noisy but it could be useful for troubleshooting.
#export CELERY_LOG_LEVEL=info

# Should Docker restart your containers if they go down in unexpected ways?
#export DOCKER_RESTART_POLICY=unless-stopped
export DOCKER_RESTART_POLICY=no

# What health check test command do you want to run? In development, having it
# curl your web server will result in a lot of log spam, so setting it to
# /bin/true is an easy way to make the health check do basically nothing.
#export DOCKER_WEB_HEALTHCHECK_TEST=curl localhost:8000/up
export DOCKER_WEB_HEALTHCHECK_TEST=/bin/true

# What ip:port should be published back to the Docker host for the app server?
# If you're using Docker Toolbox or a custom VM you can't use 127.0.0.1. This
# is being overwritten in dev to be compatible with more dev environments.
#
# If you have a port conflict because something else is using 8000 then you
# can either stop that process or change 8000 to be something else.
#
# Use the default in production to avoid having gunicorn directly accessible to
# the internet without assistance from a cloud based firewall.
#export DOCKER_WEB_PORT_FORWARD=127.0.0.1:8000
export DOCKER_WEB_PORT_FORWARD=8000

# What volume path should be used? In dev we want to volume mount everything
# so that we can develop our code without rebuilding our Docker images.
#export DOCKER_WEB_VOLUME=./public_collected:/app/public_collected
export DOCKER_WEB_VOLUME=.:/app

# What CPU and memory constraints will be added to your services? When left at
# 0, they will happily use as much as needed.
#export DOCKER_POSTGRES_CPUS=0
#export DOCKER_POSTGRES_MEMORY=0
#export DOCKER_REDIS_CPUS=0
#export DOCKER_REDIS_MEMORY=0
#export DOCKER_WEB_CPUS=0
#export DOCKER_WEB_MEMORY=0
#export DOCKER_WORKER_CPUS=0
#export DOCKER_WORKER_MEMORY=0

docker-compose.yml

x-app: &default-app
  build:
    context: "."
    target: "app"
    args:
      - "UID=${UID:-1000}"
      - "GID=${GID:-1000}"
      - "DEBUG=${DEBUG:-false}"
      - "NODE_ENV=${NODE_ENV:-production}"
  depends_on:
    - "postgres"
    - "redis"
  env_file:
    - ".env"
  restart: "${DOCKER_RESTART_POLICY:-unless-stopped}"
  stop_grace_period: "3s"
  tty: true
  volumes:
    - "${DOCKER_WEB_VOLUME:-./public_collected:/app/public_collected}"

x-assets: &default-assets
  build:
    context: "."
    target: "assets"
    args:
      - "UID=${UID:-1000}"
      - "GID=${GID:-1000}"
      - "NODE_ENV=${NODE_ENV:-production}"
  env_file:
    - ".env"
  profiles: ["assets"]
  restart: "${DOCKER_RESTART_POLICY:-unless-stopped}"
  stop_grace_period: "0"
  tty: true
  volumes:
    - ".:/app"

services:
  postgres:
    deploy:
      resources:
        limits:
          cpus: "${DOCKER_POSTGRES_CPUS:-0}"
          memory: "${DOCKER_POSTGRES_MEMORY:-0}"
    environment:
      POSTGRES_USER: "${POSTGRES_USER}"
      POSTGRES_PASSWORD: "${POSTGRES_PASSWORD}"
      # POSTGRES_DB: "${POSTGRES_DB}"
    image: "postgres:15.0-bullseye"
    profiles: ["postgres"]
    restart: "${DOCKER_RESTART_POLICY:-unless-stopped}"
    stop_grace_period: "3s"
    volumes:
      - "postgres:/var/lib/postgresql/data"

  redis:
    deploy:
      resources:
        limits:
          cpus: "${DOCKER_REDIS_CPUS:-0}"
          memory: "${DOCKER_REDIS_MEMORY:-0}"
    image: "redis:7.0.5-bullseye"
    profiles: ["redis"]
    restart: "${DOCKER_RESTART_POLICY:-unless-stopped}"
    stop_grace_period: "3s"
    volumes:
      - "redis:/data"

  web:
    <<: *default-app
    deploy:
      resources:
        limits:
          cpus: "${DOCKER_WEB_CPUS:-0}"
          memory: "${DOCKER_WEB_MEMORY:-0}"
    healthcheck:
      test: "${DOCKER_WEB_HEALTHCHECK_TEST:-curl localhost:8000/up}"
      interval: "60s"
      timeout: "3s"
      start_period: "5s"
      retries: 3
    ports:
      - "${DOCKER_WEB_PORT_FORWARD:-127.0.0.1:8000}:${PORT:-8000}"
    profiles: ["web"]

  worker:
    <<: *default-app
    command: celery -A config worker -l "${CELERY_LOG_LEVEL:-info}"
    entrypoint: []
    deploy:
      resources:
        limits:
          cpus: "${DOCKER_WORKER_CPUS:-0}"
          memory: "${DOCKER_WORKER_MEMORY:-0}"
    profiles: ["worker"]

  js:
    <<: *default-assets
    command: "../run yarn:build:js"

  css:
    <<: *default-assets
    command: "../run yarn:build:css"

volumes:
  postgres: {}
  redis: {}

tailwind.config.js

module.exports = {
  content: [
    '/app/assets/js/**/*.js',
    '/app/assets/css/**/*.css',
    '/app/src/**/*.html'
  ],
}

Also, within the run file, the build:css function reads as this:

function yarn:build:css {
  # Build CSS assets, this is meant to be run from within the assets container
  local args=()

  if [ "${NODE_ENV:-}" == "production" ]; then
    args=(--minify)
  else
    args=(--watch)
  fi

  mkdir -p ../public/css
  DEBUG=0 tailwindcss --postcss -i css/app.css -o ../public/css/app.css "${args[@]}"
}

[nickjj]

This is a tricky one to debug because my set up is nearly the same as you. I also use WSL 2 with Windows 10 and the files are within WSL 2's file system and everything is working. I also haven't seen this pop up for anyone else yet.

I don't think this will make a difference but can you sudo apt-get install inotify-tools? I don't have this package installed but I'd be interested to see if it works. You can also try adding this packages to the list of apt packages in the Dockerfile for both the Node and Python base images and rebuild things, then try again.

[adrivn]

I installed inotify-tools and set up a watch over the public folder (where the static files are deposited and the CSS output file goes, but no change is detected after I change css classes on the HTML files.

BUT if I modify the app/public/css/app.css file (alleged output file), the changes show up instantaneously on both Django (upon refresh) and the inotify watcher

The issue therefore seems to be on the watch of HTML files. IDK if there are issues with the paths, maybe..

[nickjj]

Do you have the same issue with https://github.com/nickjj/docker-flask-example? It has the same set up as this Django app but for Flask. It also uses Gunicorn too. This could help reduce the problem down if it happens to work with the Flask example app.

[adrivn]

I just tried it and yes, it has the same issue. Might have something to do w/ caching/gunicorn?

[nickjj]

We can double check that with https://github.com/nickjj/docker-rails-example if you're up for it, which is the same example app but with Rails. It doesn't use Gunicorn.

[adrivn]

I spin up the rails container and sadly, the CSS watch does not work either.

I went back and within the css container terminal I ran yarn build:css --watch (simultaneously to the one already running), which worked at first run but then subsequent updates did not work.

At this point I think it might have something to do with my system.

Edit: yea I thought so. I'm editing in Vim inside the WSL though, not using windows programs to edit.
microsoft/WSL#4739

[nickjj]

That issue you linked is when you volume mount in files from /mnt/c or any drive from Windows. You mentioned your files exist inside of WSL 2's file system which would be different. This would be independent of your editor btw.

You could still open files in WSL 2 with VSCode, Sublime Text or any other editor that's installed on Windows.

[adrivn]

FWIW here's my WSL status log output:

Default Distribution: Ubuntu
Default Version: 2

Windows Subsystem for Linux was last updated on 15/05/2022
WSL automatic updates are on.

Kernel version: 5.10.102.1

It must definitely be my system.

[adrivn]

I have been tinkering with some other WSL installs and I think I spotted a lead as to why it doesn't refresh.

I made a clean install of WSL Ubuntu, and went straight into cloning the repo and running docker compose up --build
Then I opened up Nano and edited one of the .html templates: it worked! see for yourself

with.a.clean.install.and.nano.it.works.mp4

But when I tried to do the same with Vim, and saved, it stopped working. Worse, something broke, and now if I try to use Nano to edit, it does not watch the .html files anymore.

the.moment.i.save.with.vim.it.stops.working.mp4

Hope this sheds some light on the issue.

[nickjj]

Are you editing the file in WSL 2 or did you install Vim inside of the container?

For reference my copy of Vim is installed directly in WSL 2. There's no editors installed in the container.

[adrivn]

Editing in WSL2, Vim was not installed as it was already in the distro (Ubuntu).

So the same as yours. Something "locks" the watch when Vim saves the file, as you can see. Nano had no issues until the file was saved in Vim.

[nickjj]

That is good detective work, at least we know it's mostly a localized issue.

Do you have any "interesting" Vim plugins or settings that might affect how files are saved?

My vimrc is at https://github.com/nickjj/dotfiles/blob/master/.vimrc, I'm not doing anything too crazy tho. The only thing that stands out is I have set backupdir=/tmp//,. set to keep all swap files created by Vim in 1 centralized location. I don't think that would have an affect here tho.

[adrivn]

It seems I'm not the only one to have this issue (see guard/listen#434 and https://github.com/guard/guard/wiki/Analysis-of-inotify-events-for-different-editors#vim)

I'll try your suggestion and these later on, see if I can get it to work.

[adrivn]

Playing around with inotifywait, it seems that the access method to the file impacts the --watch capabilities, and throws the worker off.

When opening an html template with Vim/Neovim, then saving:

hellodjango/src/pages/templates/pages/ CREATE 4913
hellodjango/src/pages/templates/pages/ CREATE home.html
hellodjango/src/pages/templates/pages/ MODIFY home.html

(no log upon opening the file)

When opening with Nano:

hellodjango/src/pages/templates/pages/ CREATE .home.html.swp
hellodjango/src/pages/templates/pages/ MODIFY .home.html.swp

When saving the file with Nano:

hellodjango/src/pages/templates/pages/ MODIFY home.html
hellodjango/src/pages/templates/pages/ MODIFY home.html

I am certain this behavior is what is causing the issue. Do you have any guesses as to what should be modified?

[adrivn]

I used VSCode via WSL and what do you know, the CSS watcher now works. It was all Vim/Neovim, after all.

Would you mind sharing your config, specially options related to file saving behavior/swaps? I'd like to keep using Neovim but I can settle with VSCode.

[nickjj]

My full vimrc is here: https://github.com/nickjj/dotfiles/blob/master/.vimrc, I'm using Vim 8.1 at the moment. I'm not sure what would cause this exactly but Googling for "vim inotify save" comes up with a bunch of things such as https://vi.stackexchange.com/a/25031.

In a previous comment I suggested trying to set set backupdir=/tmp//,. since maybe writing the swap file to a different directory than the watched directory could have an effect but I'm not sure. That is the only backup related setting I have unless one of the plugins I use modify other backup settings without my knowledge.

[nickjj]

Hi,

I think this ended up being a bug with TailwindCSS, version v3.2.4 has a fix and tailwindlabs/tailwindcss#7759 has a bunch of comments around file watching not working with earlier v3.2.X releases when using Vim.

I'm able to confirm that 3.2.1 won't reload CSS files but 3.2.4 does. This project is already set up to use 3.2.4 but it wasn't at the time when this issue was opened, but earlier 3.1.X releases didn't have this issue.

[adrivn]

@nickjj Nicely spotted. Thank you very much for the heads up!

[sdevgill]

@adrivn Any update on this? Having the same problem. And using Tailwind v3.2.7 so it doesn't seem to be that.
CSS file reload just fine, but when editing HTML files, I need to stop and rebuild.

[nickjj]

Are you running Django with DEBUG=true set in your .env and you built your image with that set? Also make sure DOCKER_WEB_VOLUME is set up to the correct path in the .env file. WEB_RELOAD=true should be set too in the .env. All 3 are set up to work out of the box if you cloned this repo.

Also if you're using WSL 2, make sure your files are in WSL 2's file system instead of being mounted through a Windows drive.

[sdevgill]

@nickjj Yes, all are set correctly in the .env file. And yes, using WSL2 with files directly there.

Also just cloned the repo on my M1 Mac, and editing HTML templates and reloading doesn't work there either, still need to stop and compose again. Editing CSS works just fine.

[nickjj]

@sdevgill I'm able to reproduce this.

I personally run WSL 2 too and this project absolutely worked a few weeks ago but I'm noticing that HTML templates aren't reloading as of today.

[nickjj]

I've opened a new issue to track this at: #36

Thanks for the report!