Coverage Status

Coverage decreased (-1.7%) to 95.57% when pulling 2855596 on EmilLuta:assets_support into 9dcd192 on owais:master.

Coverage Status

Coverage decreased (-1.7%) to 95.57% when pulling 2855596 on EmilLuta:assets_support into 9dcd192 on owais:master.

Coverage Status

Coverage decreased (-1.7%) to 95.57% when pulling 32a730e on EmilLuta:assets_support into 9dcd192 on owais:master.

Coverage Status

Coverage decreased (-1.7%) to 95.57% when pulling b266a74 on EmilLuta:assets_support into 9dcd192 on owais:master.

Coverage Status

Coverage decreased (-1.7%) to 95.57% when pulling 3ed8aa6 on EmilLuta:assets_support into 9dcd192 on owais:master.

@EmilLuta Thanks for the contributions. I really appreciate the time and work you put into this but I wish you had discussed this before investing all the time. I'm not sure about the way this PR changes the API of both django-webpack-loader and webpack-bundle-tracker.

BTW, you can already get references to webpack assets using the webpack_static template tag. For example,

{% webpack_static "test.jpg" %}

is replaced with the full link to test.jppg. This does not support assets with bundle hash in filename but I think that can be implement with very little or no changes to the existing API.

Hello @owais. I managed to email you a couple of times, so I thought to give it a shot at replying. Basically, what my PR adds is static files management without js. Indeed, it might've proven a good idea to have a chat before. As you stated, the changes are on both sides of the API.

If you have unclarities about how this works, let me know so we can have a look together. Basically, the only thing it does is to add files in a specific bundle, allowing them to be rendered straight from django at need as static assets.

Please, follow up in order to see whether there is a chance where we can get this merged into the current packages.

Cheers!

@owais I understand that webpack_static can be used to reverse non hashed files, but having them hashed give us useful guarantees in terms of caching (i.e. stale assets will never be used when releasing new versions). So I totally understand @EmilLuta motivations when pushing this. Basically, the lack of this is what currently impedes me from preloading resources in django templates.

I've commented here on what would be the ideal API on webpack-bundle-tracker side to do this. With that change, I imagine it should be simple on django-webpack-loader side to support it.

django-webpack/webpack-bundle-tracker#17 (comment)

I found out that it is quite easy to use the same paths in the webpack output as Django's ManifestStaticFilesStorage generates. Simply use the following snippet in webpack.config.js and ManifestStaticFilesStorage, and you're set:

 {
 test: /\.(png|woff|woff2|svg|eot|ttf|gif|jpe?g)$/,
 use: [
 {
 loader: 'url-loader',
 options: {
 limit: 1000,
 // ManifestStaticFilesStorage reuse.
 name: '[path][name].[md5:hash:hex:12].[ext]',
 // No need to emit files in production, collectstatic does it.
 emitFile: DEBUG,
 },
 },
 ],
 },

This means that you can just use require('image.png'), and {% static 'app/image.png' %} if you choose webpack's context and output vars wisely, something like this:

module.exports = {
 context: path.join(__dirname, 'app', 'static', 'app'),
 entry: {
 main: './main.js',
 },
 output: {
 path: path.resolve('./static/app/'),
 publicPath: DEBUG
 ? 'http' + (HTTPS ? 's' : '') + '://' + HOST + ':4000/'
 : '/static/app/',
 filename: DEBUG ? '[name].js' : '[name]-[chunkhash].js',
 chunkFilename: DEBUG ? '[name].js' : '[name]-[chunkhash].js',
 },
 resolve: {
 extensions: ['.js', '.jsx'],
 modules: ['app/static/app/'],
 alias: {},
 },
// .....
}

@matthiask thank you, useful tip!

@rvlb could you please check if this is necessary right now and how/if this is supported by current master?

Hi folks, closing this PR for now. We've added a tutorial on our readme on how to access the assets using webpack_static.