feature: dumping stats about each entrypoint and the chunks it uses

[alihazemfarouk]

This makes it possible for django-webpack-loader or any similar packages to automatically include all assets for a particular endpoint, making it possible to have webpack split vendor code into small chunks and ship the least amount possible of code.

The change is backwards compatible as it only adds the key "entryPoints" to the json stats file.

The corresponding PR for django-webpack-loader (that makes use of this new key) can be found here

[scdekov]

Do you think there is a benefit of having that extra level of nesting that can be seen in the last commit? If not I would say to flatten it, IMO it is more simple flattened.

[alihazemfarouk]

@scdekov I thought it would be better to follow the same format that's already being used in "chunks" key. Every entryPoint consists of chunks and every chunk consists of (possibly) multiple files

[scdekov]

@alihazemfarouk ok, maybe there is some use case that I'm not familiar with. I think this PR is ready for closing.

[persocon]

👍

[persocon]

can we merge this please? 🙏

[bhrutledge]

@owais @alihazemfarouk @scdekov

First, thanks for all of your work to keep this up-to-date with webpack.

I'm considering django-webpack-loader for a project, and encountered the issues around optimization.splitChunks as described in https://github.com/owais/django-webpack-loader/issues/157 and https://github.com/owais/django-webpack-loader/issues/165. I though it would be useful to round up all the relevant links here, for folks to review.

This PR and https://github.com/owais/django-webpack-loader/pull/182 seem to offer a viable solution. This PR also seems to take precedence over https://github.com/owais/webpack-bundle-tracker/pull/37.

I installed django-webpack4-loader and webpack4-bundle-tracker (which incorporate the PR's above), and the render_entrypoint template tag behaves the way I hoped.

Is there anything blocking the merge of these PR's, and if so, how can we help?

[joshgeller]

Any updates here? How can we help get this merged? Thanks!

[arvindamirtaa]

This would be ideal for my use case. Looks like it's been open for a while. How can we help?

[tony]

@owais This PR is a blocker for splitChunks support in webpack v4. Any thoughts on merging this? It looks like this approach is backwards compatible and would give us the right data in the manifest to render split bundles.

[tony]

@alihazemfarouk Nice job on this and @bhrutledge great job reading through and making sense of this. There's a bit of coordination involved since we need the right data in the manifest file (from webpack-bundle-tracker) to get bundles rendering the way we want.

[greggb]

It's pretty clear this package has gone dormant*. Moving on with the fork is probably a good idea for anyone looking to use webpack4. I did this a few weeks ago and it's working well. A few gotchas:

• pip uninstall the python module before re-installing the fork
• Watch the naming conventions closely (webpack/webpack4) as the docs are not consistently updated with this.

*Totally understandable for an author to move on - no blame here, and much appreciation for all the work keeping it going so long.

[tony]

@greggb

*Totally understandable for an author to move on - no blame here, and much appreciation for all the work keeping it going so long.

I've been reading this issues, where does @owais say he isn't maintaining this anymore?

[greggb]

I've been reading this issues, where does @owais say he isn't maintaining this anymore?

I'm making this assumption based on activity.

[tony]

@greggb Understood. To avoid derailing this thread, I created a thread at #46 to ask if @owais would like help maintaining the projects (since these are pretty popular packages and there seems to be many willing to help out!).

[owais]

We released 1.0.0-alpha.0 that has webpack 4 support (thanks to @melck). Can someone verify if this is covered by the new alpha release or if something more needs to be done?

[tony]

@alihazemfarouk can you rebase this against master and see if it includes anything extra we want to throw in while we're here?

CC: @owais

[andersk]

This has been superseded by at least one of #53 or #66.