Simplifying the Static Build Process in Django Starter Projects
Our third iteration in reducing the tooling overhead to support a decoupled static build process in our Django project templates is proving itself well.
In February 2016, I wrote about our 2nd iteration in the decoupling of the static build process in the Django starter project templates we have in Pinax.
That iteration focused on moving from webpack to gulp scripts due to the friction we were having with webpack at the time, mostly due to the lack of transparency of what was happening when.
Gulp gave us much more control and clarity of the pipeline which made things easier to debug.
As more of the build tools we were using got better command line interfaces (or maybe we just discovered them), we decided to take a step forward to even further simplify the build process. Now we don’t even need the big collection of gulp scripts. We just invoke the command line tools directly in a set of
What’s nice about this is now all of our static processing is handled in one file that starts out at about 50 lines long. Even if you don’t know anything about how npm / node work, it shouldn’t take a developer long to at least intuit how some of the things are working. Furthermore, tweaking the build processes is just a matter of editing the command lines in the
Included in this process is a new way to get going in development. You can still use the well known method of using
runserver by making sure you build your static media first:
npm run build
However, a cool thing, especially for doing any frontend development are the addition of browser-sync and watchers. Now you can simply run:
browser-sync proxy also provides some tools that you can access on port 3001 that can help you debug frontend requests, simulate different bandwidth conditions, and more.
Consider joining us in the Pinax Slack and let us know what you are building or how we can help.
Originally published at blog.pinaxproject.com on September 8, 2017.