Add option to disable manifest caching

[Dresdn]

This PR introduces a new configuration option cache_manifest (default: True) that allows users to control whether the manifest file should be cached.

Problem

Currently, when making changes to assets during development without using HMR, you need to:

1. Modify the asset file
2. Run vite build to generate new assets
3. Restart the Django server to reload the manifest

This is somewhat annoying as I find myself constantly forgetting to restart the Django server for minor tweaks to a Javascript asset.

Solution

With this setting, I can tell django-vite to reload the manifest on each page request without having to restart the server.

Before I add in docs and tests, I wanted to get some feedback.

[gegoune]

I don't think you are using correct workflow for local development. Why aren't you using dev server locally?

[MrBin99]

Hi, I agree with @gegoune why do you not want HMR and dev server in development ?

[Dresdn]

Thanks for the questions!

Why aren't you using dev server locally?

I never said I wasn't. The point of this PR is to not require people to run the dev server or restart Django when doing frontend changes.

Here's some background and extra context: we use django-split-settings, and there are 3 "environments":

1. Productions
2. Development
3. local.py (allows overriding any settings locally)

The team is also composed of those who primarily focus on frontend, backend, or both. The frontend developer will 100% set dev_mode: True and use HMR. The backend developer will just need a one-time build, and using HMR isn't necessary.

As the lead, the issue then lies: Which one should be the "standard" to use for local development? Should I inconvenience the Frontend or Backend developer?

I'm a fan of a few things:

1. Giving people a choice around how to work (hey, you wanna knock nails with a wrench, go ahead)
2. Mirroring local development as close to Production as possible (which has already happened with HMR)
3. Compromise

This PR fits those three principles: I can mirror my Development environment by default by requiring production-level frontend assets to be built, a developer can choose to enable the HMR in their environment with the local.py override, and it is a great compromise for a diverse team.

[akx]

👍 for something like this – I'm trying to switch our multi-page, many-entrypoint app from Webpack to Vite, and I'd like to get the production-ish build (vite build --watch in one terminal tab) to first work, and only then go on to get dev mode with HMR to work.

Right now I need to restart the Django server with every rebuild, which is a bit of a chore.

FWIW, Whitenoise also supports this sort of thing with WHITENOISE_AUTOREFRESH.

[Mr0grog]

Even though whatever code was suggested for this is gone, I would really appreciate this functionality, too!

At the moment, I am hacking something like this in at runtime. While I expect to mostly be using Vite’s dev server, it is really valuable to be able to treat assets more like they will work in production. Sometimes HMR or JS-based loading of CSS hides problems (see also: #166). This also seems pretty closely related to #48 — I think the use cases and needs people are trying to solve for are basically the same.