Switch from jingo-minify to django-pipeline#2401
Conversation
|
Funny this--@mythmon and I were just talking about switching to gulp for everything or something like that. |
|
/me nods. that could be interesting, but i think that would likely be a much larger change. i think while we figure out what that looks like this is a pretty good change. it already cuts out the double-refresh thing that i find super annoying while developing. |
|
OMG. I hate the double-hard-refresh thing. |
|
This is failing the Travis thing because it can't find lessc. Just as an eff why eye. |
|
@willkg it was but i fixed that in my second commit. the qunit tests page was broken but i just fixed it ^ |
|
Just as an eff why eye, I'm so glad you're doing this. I'm so going to do this for fjord, too. |
|
Also, I'm just chatting right now. I can review this on Monday (i.e. 24 hours from now) if other people don't get to it first. |
|
I think we convert this PR into a sumodev message board. 👍 |
|
haha! i was actually just about to do this for fjord! |
|
Ditching WTFinder is totally unacceptable. r- |
There was a problem hiding this comment.
If we don't do this at compile time, does it happen at request time? Or does collectstatic now do the compress_assets part?
There was a problem hiding this comment.
collectstatic handles everything
|
Looking at pipeline, I like it. It seems to have pluggable compilers and minifiers, so that's really cool. It has an es6 compiler that uses Babel, which I'm a big fan of, and in particular Babel supports the jsx compilation I'm going to need to do for my React stuff. This makes me much less gung-ho about using Gulp for all this compilation stuff, since pipeline seems to be able to handle it all. All these changes look fine, I have a small question about when compilation happens, but besides that, yay! The tests are certainly a problem, but I bet that is fixable. |
|
So... I spent some time figuring out what was going on with the tests. On my machine, kitsune tests take:
22m is crazy. I want to do this for Input, too, because I like jingo-minify like I like ham and cheese sandwiches drenched in used motor oil so I spent some time looking into it. After some experimentation, I discovered that if This sort of makes sense. Pretty sure that's the only environment where it could potentially pick up the wrong value. I didn't know whether this means we have to run collectstatic before a test run or not (we do for Input (which is using jingo-minify)). I removed Also, on a positive note, the tests with this branch and And that's all I have to say about that. |
|
updated ^ /me crosses finger. |
|
tests pass in a normal amount of time. thanks for looking into that @willkg! r? |
There was a problem hiding this comment.
I think this should be just jqueryui?
|
fixed ^ |
|
The changes look good. I'm going to test it out. |
|
This works for me. Lets see how it does on stage. r+ |
|
I deployed 5df4075 to stage, and checked that it worked with cache busting. It did, so that's cool. It also cache busted a bunch of our other assets, including a sprite sheet we were manually cache busting. Nice! I think this is ready to go. |
Switch from jingo-minify to django-pipeline
|
WOO HOO!!!!111!!!11!! 🎈 👍 🎆 |
3 participants
I've been exploring switching to Bower to handle all our front end dependencies and one of the first issues we run into is that jingo minify needs to land my changes that fix relative url's in CSS files. Since that pull has been opened for a few years and the general maintenance of jingo minify is not the greatest I decided switching to django-pipeline was a better option. The switch was way simpler than I expected.
Some things to note:
settings_local.pywill need to be updated on each of the server before we deploy this and then probably again to remove the jingo-minify stuff once we have finished deploying/testing this.cleancsstocssminsince I didn't feel like writing a django-pipeline compiler forcleancss.r?