If CACHE=True, any changes made in the assets files will only be read when the web workers are restarted.ĭuring development, when the stats file changes a lot, we want to always poll for its updated version (in our case, we'll fetch it every 0.1s, as defined on POLL_INTERVAL). If CACHE=False, we'll always read the stats file to get the assets paths. From that point onwards, it will use these stored paths as the source of truth. Since in a production environment ( DEBUG = False) the assets files won't constantly change, we can safely cache the results ( CACHE=True) and optimize our flow, as django-webpack-loader will read the stats file only once and store the assets files paths in memory. 'IGNORE': ,įor that setup, we're using the DEBUG variable provided by Django. You can compile the assets and generate the bundles by running: You must generate the front-end bundle using webpack-bundle-tracker before using django-webpack-loader. The generated compiled files will be placed inside the /assets/webpack_bundles/ directory and the file with the information regarding the bundles and assets ( webpack-stats.json) will be stored in the project root. The configuration above expects the index.js (the app entrypoint file) to live inside the /assets/js/ directory (this guide going forward will assume that all front-end related files are placed inside the /assets/ directory, with the different kinds of files arranged within its subdirectories). What I ended up with was an extension of WebpackBeforeBuildPlugin which simply polled for the existence of the required file.Const path = require ( 'path' ) const webpack = require ( 'webpack' ) const BundleTracker = require ( 'webpack-bundle-tracker' ) module. I was tempted to find a more streamlined solution, one that would allow me to run webpack the way that you'd expect.
This requires some fiddling with your CLI usage, but does ensure that one config completely finishes before starting the new one. One option is to break apart the build and manually build each configuration in isolation. The internet had a few things to say about this. If the file exists before the build runs, then everything flows smoothly, so the question became how to make it work without the pre-existence of that artifact. I've deduced that the configurations are being built in parallel, because even though the client configuration successfully creates the new file (I can see it in the build logs, and I can see those logs before I see any mention of the server build), the server build fails with a "I can't find that file!" error.
0 kommentar(er)
