Entrypoint-based loading #261
Conversation
…nto jezeniel-patch-3
…sts-to-webpack4 Chore/update tests to webpack4
# Conflicts: # README.md # webpack_loader/config.py # webpack_loader/utils.py
|
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 |
|
@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 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 As it was mentioned above, #232 changes the 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. If you can't do it, please let us know too and we'll try to prepare a new PR with those commits. |
# Conflicts: # .circleci/config.yml # .gitignore # README.md # examples/hot-reload/templates/home.html # examples/hot-reload/webpack.config.js # examples/simple/webpack.config.js # requirements-dev.txt # setup.py # tests/app/tests/test_webpack.py # tests/assets/js/index2.jsx # tests/db.sqlite3 # tests/package.json # tests/requirements/common.txt # tests/requirements/django18.txt # tests/requirements/django31.txt # tests/requirements/django32.txt # tests/tox.ini # tests/webpack.config.app2.js # tests/webpack.config.error.js # tests/webpack.config.gzipTest.js # tests/webpack.config.simple.js # tests/webpack.config.split.js # webpack_loader/__init__.py # webpack_loader/loader.py
|
Since multiple entrypoints seem supported in the new version, I'm closing this - thank you for the initial support. For the |
In my fork of
django-webpack-loader, there is a bit of added functionality, cleaned up code, etc. Primarily, the new webpack versions are supported and the concept of entrypoint-based resource management.I maintain the PyPi package
django-webpack5-loader.Purpose of this Fork
This package aims not only to support webpack 4 and 5, introduce additional loading of entrypoints in templates,
but also adds a framework for structuring django projects into pages using
webpack_loader.contrib.pages.See below.
The initial webpack 4 port was made possible thanks to
apart from the original package author Owais Lone.