Add templatetag and staticfiles storage for Django

[rockymeza]

Hi,

I made a templatetag and a storage backend that allows you to pre-compile the webpack bundles. I modeled the interface sort of close to django-compressor's offline mode and the code for the WebpackOfflineStorageMixin is based on the ManifestFileStorage from django.

I also adding some docs for how to use it, but I wasn't sure where you would have put the docs, so I just made a new section for it.

Before you merge this, I think we need to write some tests for the WebpackOfflineStorageMixin, but in order to do that, we need a way of overriding the settings, which is a little hard with the optional_django stuff. Do you have any idea for what we could do with that?

Thanks!

[markfinger]

Wow, that looks really cool. I'll get back to you when I've got some free time to give the code a proper read

[markfinger]

Regarding the settings and testing, it's probably easiest to accept the values as args in the constructor.

This'll mean we can test them easily, rather then relying on access to the settings singleton

[markfinger]

If that's not too easy, you could maybe use a factory which stubs out enough to get things working

[rockymeza]

now with tests and lots of mocking

I think there is one controversial piece of code in here, which you can see in this test

My idea was that I might only have the js-host server running during collectstatic, or I might run collectstatic locally and rsync the files to the production server. So I was planning on disabling the webpack bundling in-request if COMPRESS_OFFLINE=True. What do you think?

[markfinger]

Cool, thanks for all of that. I'll have some free time in a day or two to properly look it over and merge this in.

Regarding the disabling of bundling, I'm inclined towards the same. Given the build times required for most bundles, you don't want a production instance to freeze while the bundle's being generated. If someone opts-in to using a manifest, it's better to be explicit and simply throw an exception when an unknown bundle is encountered.

When I merge it in, I'll take a stab at opening up pre-compilation for non-django systems - I work with django myself, but it'd be nice to decouple it. This might mean changing the webpack.compiler.webpack function to use the manifest, rather than hitting the node server.

Another TODO is to handle programatically generated config files which have dynamically generated names, which happens in python-react. I suspect that the list of bundles will need to take callbacks, so that you can generate them during runtime.

Once again, thanks for this!

[markfinger]

Merged into the precompiler branch. I'll hack on it a bit, then merge it into master.

@rockymeza, thanks again!

[rockymeza]

Thanks!

-rocky
2015年5月18日 上午5:25于 "Mark Finger" notifications@github.com写道：

Closed #20 #20.

—
Reply to this email directly or view it on GitHub
#20 (comment).

[markfinger]

There's something akin to your PR on master now, although it's deviated quite a bit.

I moved the manifest generation up into webpack-wrapper; where it generates them as part of a caching layer. The caching layer massively improves the time to first build when you first boot a server, it also keeps track of the bundle's file deps and checks mod. times on the deps and config files before serving the compilation output, so that'll hopefully avoid most issues regarding stale caching. In dev, it'll still spin up the watcher and - once it's ready - let it take over from the cache, so perf should be a lot better.

The python layer knows how to read those cache files, so a precompilation stage boils down to just iterating over every config file and letting the compiler generate the file. In prod, you can turn on USE_CACHE_FILE, which means that the python layer reuses the file, rather than relying on the compiler.

I stripped out the file storage which precompiled things during collectstatic. It seemed a bit magical to me, and in a lot of use cases it requires you to either override the global file storage or have a stage where you mixin a bunch of classes. I can appreciate the convenience, but I think it's better to have it as an explicit stage, hence I added a populate_webpack_cache command.

Anyway, this is all on master, but I'll push a new version up to PyPI in a couple of days. There are a couple of breaking changes still to land - mostly setting changes.

Thanks again, @rockymeza!

[rockymeza]

I think yours is probably a better solution for eventual other-framework interop. Thanks for getting something like this merged!