I think that’s out-of-scope for the dev watchers config, per the docs

:watchers - a set of watchers to run alongside your server. It expects a list of tuples containing the executable and its arguments. Watchers are guaranteed to run in the application directory

Basically the :watchers option just says “hey also run these things”, but it doesn’t actually “watch” for changes and then run them.

So what you want to do is configure vite watch to also track *.heex file changes in lib/ (or the priv/static/assets/**.css or whatever is the actual change you want to get picked up).

I think the term might be a bit confusingly labelled but there probably also isn’t a better choice.

My understanding is that @soup’s answer is correct. You have to ask Vite JS to watch the template files too.

The default webpack generator would have been pre-configured with the right paths probably.

• I tried specifying the template files as a glob lib/**/*.*ex - and - the live reload is taking close to 10 seconds or more to reload the page - with unpredictable results. Sometimes, the new styles are getting picked up and sometimes, only cached styles are working.

Sometimes I see this with tailwind because the JIT used to write its results out in parts, you can configure the live reloader to wait an interval before it messages phoenix: GitHub - phoenixframework/phoenix_live_reload: Provides live-reload functionality for Phoenix · GitHub

• With tailwind standalone we were putting
  tailwind: {Tailwind, :install_and_run, [:default, ~w(--watch)]} in the config/dev.exs - that ~w(--watch) watches which folders? I guess, I need to specify something similar.

Tailwind will be using tailwind.conf.js’s content: key to know what to look for. I think it’s content, it used to be purge until 3.0. That file may not exist, tailwind might use a default one if it is missing.

Probably your best bet is to remove dev.ex and the live reloader from the equation first. Get your tailwind and vite builders and watchers working manually from the command line, in a way that doesn’t fight each other, then just copy the setup into dev.ex, and where ever you are also running them for prod builds.