If we used something like https://django-compressor.readthedocs.io/en/stable/ then we could simply remove the compress assets management command and totally internalize the compression process.

There are a few compatibility issues though, so would need to verify this or some other equivalent package would even work.

We could also consider bundling the assets using a javascript/web bundler like webpack/rollup/vite.

Instead of managing the bundles via MINIFIED_BUNDLES in django, we could simply reference build artifacts and let the npm tool do the building. This being isolated from django could be run in a separate stage and only depend on the static folder.

I am django-compressor maintainer, and I would recommend against using it. It's not meant for big/complex websites, and is not really in a place where it can compete with modern bundlers (I suspect all django packages for assets management suffer from the comparison with modern npm bundlers as well).

TIL 👋

We could also consider bundling the assets using a javascript/web bundler like webpack/rollup/vite.

Instead of managing the bundles via MINIFIED_BUNDLES in django, we could simply reference build artifacts and let the npm tool do the building. This being isolated from django could be run in a separate stage and only depend on the static folder.

https://github.com/MrBin99/django-vite fwiw (not checked out beyond the readme)

One method I had played around with but not fully verified is something like

1. replace MINIFY_BUNDLES dictionary with a manifest file, either yaml or json (this so we don't need django/python to read the assets
2. define a rollup/webpack/vite build based on those configured bundles (like we have now with compress_assets just replacing the tool)
3. make sure the path of the output bundles can be inferred by the input path, via a manifest or some heuristic
4. update our jingo_minify_helpers to read the output file path via the output manifest.

This seems a lot like withat django-vite is doing, maybe? I'm fairly confident something like this means we can delete the compress_assets file and run the bundlificiationismination as a standalone stage and cache it to the depths of hell, unless you change an asset.

Old Jira Ticket: https://mozilla-hub.atlassian.net/browse/ADDSRV-775

Needs a spike to investigate this.

Notes so far fyi @chrstinalin

1. look at this ticket for mapping django template tags to jinja2 compliant tags
2. look at this example repo for how to setup

• we should define a docker-compose service for running vite that will compile all the assets during development.
• this service should be available over docker network to nginx which can expose to open internet
• we use the django_vite vite_asset to compute a script tag which resolves to the url -> nginx -> vite server asset directory.

Now loading assets in dev is almost the same as in prod. This "should" work.