Correctly understood.

I think this is a reasonable feature to add.

Let’s use a dict setting like:

DJANGO_BROWSER_RELOAD = {
    "events": {"static", "templates"},
}

My biggest concern is that server reload “events” work differently and may not make sense to disable.

Would you like to make a PR?

Right, it may not make sense to disable server reloads.

I'll work on a PR.

About the setting, I feel it might be strange to ask users to explicitly list all the events they want to enable, when all they want is (most likely) to disable just one.

Also, future upgrades might be easier for users if they specified just the events they want to ignore. If new events ever get added to django-browser-reload in the future, then users would benefit from those being enabled by default even if they had disabled a specific event in their config. Of course, it doesn't seem very likely that new events will be needed in the future, but who knows...

What do you think?

I use this great tool (thanks @adamchainz and contributors) and I just went there because I have a need that looks like this one, but with more granularity: ability to ignore changes on some extensions.

My use case may be too specific but just in case here it is: I use normal django templates, statics, EXCEPT for a specific part where I write some typescript that is compiled to js. The problem is that the reload is triggered by the typescript change and often not by the compiled js changes because it happens too fast. Or at the best I have two reloads. So the ability to ignore ".ts" files, for examples (why not ".less" files, or other) would be great.

Do you think it is something that may be in this project and if yes, if it's in the scope of the current issue? I can help write a PR for this based on the one from @davidlesieur if needed.

@twidi Have you considered placing your .ts files in a separate directory from your other static files? I think django-browser-reload won't trigger if the files are not found by Django's static files finder.

yes of course I can do that, I just wanted to have everything "front" related at the same place ;)

thanks for the tips

@twidi On some projects, I have started putting assets that Django does not really need to know (Sass stylesheets, uncompiled JS) into static-src directories, which are siblings to my static directories. In fact, it seems nice to distinguish which directories matter to build tools (static-src), and which matter to Django (static). This way, collectstatic also leaves out anything from static-src, which don't need to go public.

This totally makes sense