Webpack 5 works quite differently than webpack 3, indeed. The 'constant' assets are much more focused around the entrypoints. It makes a lot of sense, as a Django dev trying to shield themselves from JS complications, to include the full entrypoint in their page. Since including chunks can have dependencies on other chunks. Webpack changes, but that's great isn't it? :)

With entrypoints, one simply defines an entrypoint for a page and include it automatically, by just referencing e.g. the "index" entrypoint once. That can of course also include CSS.

You can however, still include the chunks manually. When using the common SplitChunks optimization, this can be painful.

So I think in order to only include webpack chunks, the npm package webpack-bundle-tracker requires no change.
For this merge request, anyone can use webpack4-bundle-tracker, which already has this functionality (also works for webpack 5). A respective pull request and update would be a great idea I think.

@owais I like the idea of shielding Django and facilitating the integration with JS build systems. IMO that definitely that can be a long term goal for the project.

I'm studying how entrypoints work and I'll give a feedback here.

My view is that there is no need for a separate render_entrypoint directive. We should instead modify the existing render_bundle to take an entry point and load every chunk in that entry point’s chunk group. It is entry points that are the user-facing concept, and chunks that are the webpack implementation detail, not the other way around. It makes no sense to load a specific chunk from a chunk group that has multiple chunks (unless you have a trivial non-optimizing webpack configuration where each entry point has a chunk group with exactly one chunk of the same name, in which case it makes no difference).

The main webpack-bundle-tracker already works with Webpack 5 and exposes the necessary information about entry points/chunk groups. This was added in django-webpack/webpack-bundle-tracker#53 and released in webpack-bundle-tracker 1.0.0-alpha.1. All that’s missing is support in django-webpack-loader (#232).

@andersk yes, thanks for this input, that's what I'm thinking as well. We're checking this PR and the related open ones and we'll merge soon.

I think so too, the whole point of keeping the bundle functionality was not breaking existing implementations. Therefore, I kept it entirely separated. I don't use it and with webpack 4 or 5 I wouldn't know loads of applications to that for Django devs, even though they are still possible.

Hi @MrP01 and @owais, we (me and @fjsj) have opted for proceeding with the merging of #232. We'll do it tomorrow and we'll release a new version to ensure compatibility with webpack-bundle-tracker@1.0.0-alpha.1.

As it was mentioned above, #232 changes the render_bundle implementation instead of creating a separate render_entrypoint for a similar purpose. We think that's the best approach, because it means supporting webpack-bundle-tracker, instead of changing to webpack4-bundle-tracker.

We see there are additional changes like tests in this PR that can be useful, but it would be best to address them in another PR.
We'll let you know here once we release the compatibility with webpack-bundle-tracker@1.0.0-alpha.1. Once the compatibility is there, could you please open a new PR with the additional changes this PR has?

If you can't do it, please let us know too and we'll try to prepare a new PR with those commits.

Since multiple entrypoints seem supported in the new version, I'm closing this - thank you for the initial support.

For the webpack_loader.contrib.pages functionality, take a look at django-webpack-pages.