Enable multi-app configs

[Niicck]

This PR adds the ability to use multiple vite configs.

Check out this repo for examples of how to use it: https://github.com/Niicck/django-vite-examples

Previous discussions:

• Added config mechanism for running multiple vue apps (on different ports) #46
• closes Support Multiple Vite Apps in Django Instance? #88
• feat(multi-config): rework how configuration definition is handled #50

What does this PR change?

1. It introduces a new (optional) way to set DJANGO_VITE={...} settings
2. The code in DjangoViteAssetLoader has been split up to help multi-app loading and separate concerns.
3. No more DJANGO_VITE_ASSETS_PATH

1. There are new settings

Instead of tying django-vite config values to root settings values (DJANGO_VITE_DEV_SERVER_HOST, DJANGO_VITE_DEV_SERVER_PORT, ...) we can now set values for distinct apps within a single DJANGO_VITE setting. This matches the way Django's database and cache backends are set, as well as django-webpack-loader.

In settings.py:

DJANGO_VITE = {
  "default": {
    "dev_mode": True,
    "static_url_prefix": 'custom/prefix'
  },
  "app1": {
    "manifest_path": STATIC_ROOT / "app1" / "manifest.json"
  },
  "app2": {
    "manifest_path": STATIC_ROOT / "app2" / "manifest.json"
  },
}

In your templates, you can specify the app you want to use:

  {% load django_vite %}
  {% vite_asset "src/entry.ts" app="app1" %}

If you don't specify an app, it'll use the "default" config.

  {% load django_vite %}
  {% vite_asset "src/entry.ts" %}

This is totally backwards compatible with our existing settings. For now, we still parse the legacy django-vite settings and assign them to the "default" app. Developers can keep using django-vite as though nothing has changed.

2. DjangoViteAssetLoader has been split up

MrBin started an implementation of this feature last year (#50). I started by bringing that implementation up to date with master (Niicck#1). While doing that I found some opportunities to split our logic up into discrete classes.

Splitting up responsibilities made it a lot easier to safely isolate configs between apps. It should also make future testing and development easier.

The core of the django-vite logic has been split into these 4 classes:

• DjangoViteAssetLoader is still the main entrypoint that our templatetags use. It parses our settings.py and constructs DjangoViteAppClients for each app that we define. But now it routes methods like generate_vite_asset to DjangoViteAppClient.
• DjangoViteAppClient is now the class that handles all of the logic for generating tags for a particular app.
• ManifestClient handles manifest.json parsing and ManifestEntry retrieval.
• TagGenerator handles tag generation.

3. DJANGO_VITE_ASSETS_PATH is removed

That's the one setting I didn't port over. Turns out, it was required, but never actually used.

DJANGO_VITE_STATIC_ROOT = (
    DJANGO_VITE_ASSETS_PATH
    if DJANGO_VITE_DEV_MODE
    else Path(settings.STATIC_ROOT) / DJANGO_VITE_STATIC_URL_PREFIX
)

The only purpose of DJANGO_VITE_ASSETS_PATH is to create the DJANGO_VITE_STATIC_ROOT when we're in dev_mode. But DJANGO_VITE_STATIC_ROOT is never used when we're in dev_mode.

The docs are correct, wherever you do end up placing your compiled vite assets, that should be added to STATICFILES_DIRS. But that's true of any static file in Django. There's nothing special that necessitates the use of this particular variable. Definitely keep the note about putting your compiled assets into STATICFILES_DIRS, but drop the requirement to set that explicit variable.

What's going to change for people who don't want to use multiple vite apps?

If they want to keep using the legacy settings, they are welcome to do so. This PR is 100% backwards compatible. But existing users would not longer need to set DJANGO_VITE_ASSETS_PATH.

Next steps

We're ready to launch!

• Tests are written
• Documentation is updated
• Sample app created

I found 1 bug with doing HMR with multiple apps on the same page, but it's not a regression so I'm not worried about it right now.

It'd be good to get some eyes on the code. Feel free to share your thoughts, ideas, concerns.

[ludwis]

Hi, when this PR could be merged? I really need that functionality.

[thijskramer]

I can merge it. Should we release it with a major version bump, to 3.0?

[Niicck]

I can merge it. Should we release it with a major version bump, to 3.0?

Yeah, I think a bump to 3.0 would be good.

And while we're at it, I think the release to 3.0 would be a good time to change the default port to 5173. #51

[thijskramer]

And while we're at it, I think the release to 3.0 would be a good time to change the default port to 5173. #51

Are you currently available to apply that change?

[Niicck]

And while we're at it, I think the release to 3.0 would be a good time to change the default port to 5173. #51

Are you currently available to apply that change?

yep. #99