Falling back to static in production

[jptaylor]

@owais great work on this loader. In my use case, I like to build and post-process my production bundles locally and build them into the django project's static folder. These get deployed as part of collectstatic, and benefit from the staticfiles hashing mixin which works great.

To keep my setup, I was wondering if there was a case for having the loader fallback to the standard static file loader when in production?

Example:

{% render_bundle 'main' default='js/main.js' %}

which is effectively the same as writing:

{% static 'js/main.js' %}

[owais]

Hi Jon. Interesting use case. It would be simple to add support for this but it sort of defeats the purpose of this library. Do you really need django-webpack-loader for this?

You can use webpack exactly the way you use with dango-webpack-loader but change a few small things to achieve what you want.

1. Don't use webpack-bundle-tracker plugin
2. Don't use django-webpack-loader
3. Configure webpack to generate bundles without hashes in them by changing

output.filename = "[name]-[hash].js"

to

output.filename = "[name].js"

This will generate bundles with predictable names. You can then tell django to collect them and use one of the caching mechanism provided by django, including content hash + infinite cache headers.

[jptaylor]

@owais thanks for the suggestions. I guess I'm trying to find a place where I can use the loader in development but not in production.

Perhaps a simpler fix would be to just use the dev server URL as my STATIC_URL.

Thanks for your comment. I'll reopen if I revisit and propose a PR.

[owais]

Sounds good. I'm curious. Why do you want to use this during development and not in production? I suppose to make django requests block in dev until webpack build finishes?

[jptaylor]

Primarily so I can prevent setting STATIC_URL to an absolute URL and retain the benefits of having multiple static sources (i.e. STATIC_DIRS). I'll acknowledge that the use case is a little weird.

Plus I'm already manifesting my files as part of storages. Even with cache, having two json mappers at play seems troublesome.

[owais]

Thanks for your comment. I'll reopen if I revisit and propose a PR.

Closing for now.

[silouanwright]

@owais

We're running into a similar issue, and your advice would be appreciated.

Currently we have a setup where we use django-webpack-loader on the development side to facilitate our webpack-dev-server usage. In production, it gives us the static file.

The problem is, is we have different environments we deploy builds to, but we build before we deploy to these environments.

So essentially we're looking for a way to preserve the fast compile time of webpack-dev-server for developers, while providing static assets on production, and in different environments.

You have any advice? What @jptaylor was referring to would actually work perfectly for us. Either adding that feature, or letting us know how we could fork this library to add that functionality would be super helpful.

[owais]

It's hard to advice without having more information about your build system. You say,

The problem is, is we have different environments we deploy builds to, but we build before we deploy to these environments.

and

So essentially we're looking for a way to preserve the fast compile time of webpack-dev-server for developers, while providing static assets on production, and in different environments.

Are you production builds much slower than local webpack-dev-server builds? You can modify your production webpack config file to speed them. If you CI system allows some sort of caching, you should be able to leverage some webpack features for incremental builds even in CI.

What exactly is the issue you are facing in production builds?

[silouanwright]

@owais Apologies. I'll attempt to provide as much information as possible. I'm just the front end developer.. hopefully I can get one of the backend developers on our team to chime in.

• We don't have continuous integration
• Multi part answer to the production build vs local webpack-dev server build:

1. One of the reason the production build is slower is because we're uglifying, extracting css, and using a bunch of stuff. That part is completely understood though.
2. I know a lot of people use webpack-dev-server it for hot reloading, live reloading, etc. We'd like the ability to keep using this as it's faster than having to continue to refresh the browser.

• The way the webpack-stats.json file works, is you run your webpack build, and it spits out a file that contains paths to all the resources. The way we deploy to production, is we create our builds, and then put the builds on production.

As you know, the variables that controls where the static files are, will vary given the settings. Because the settings we have are different from environment to environment, the build that happens before it's put on a production server doesn't work.

We don't use or have npm in production... and even if we committed this webpack-stats.json file, the paths are likely to end up being wrong as the static file variables and paths can be different from environment to environment.

So essentially, we'd like the ability to continue to use webpack-dev-server for development, and create production builds without having to rely on webpack-stats.json spitting out paths based on the static file settings of whatever environment you created the build.

This make sense? I can elaborate on whatever is needed.

[owais]

Do you only want to use webpack stats (hence webpack-loader) in development but not in production? If so, you can turn off hashing in your production webpack config so that webpack builds files like main.js and libs.js instead of main.84832744.js. Then you can configure webpack to store these files in one of the static directories. From there, you can just run django's collectstatic command and it will pull those files and put them at the static files destination for your production server. This can be just another directory on your server or something like S3. Django's collectstatic command can also add it's own content hashing so your assets are cached forever. You can use django-whitenoise or django-pipeline to handle this.

In development, you can continue to use django-webpack-loader by using render_bundle tags in the template and in production you can use django-pipeline's or whitenoise's method in templates. You can also create a very simple template tag that checks if DEBUG==True/False ans uses the appropriate tag.