Strange cache-busting behavior for `.woff2` files linked from CSS

[zane]

I'm having an issue with the cache busting feature <-> font assets. With optimizations on I can see Optimus rewriting the CSS to include cache-busting prefixes, but it's still serving one of the assets w/o the prefix, which results in a 404 when the browser later attempts to fetch it. Weirdly, this appears to be only happening for one resource, a .woff2. I created a (somewhat) minimal sample repo to assist with diagnosis if that helps.

[zane]

optimus.assets.load-css/css-url-re finds it just fine, which makes sense since it's rewriting the URL with the prefix.

[magnars]

Thanks, I'll take a look at it!

[zane]

Interestingly,

optimus-woff2-demo.core> 
(->> (optimus.optimizations/all
      (get-assets)
      {})
     (filter #(= (:original-path %)
                 "/font-awesome-4.4.0/fonts/fontawesome-webfont.woff2"))
     (first)
     (:path))
"/font-awesome-4.4.0/fonts/90453029f7e5/fontawesome-webfont.woff2"

but /font-awesome-4.4.0/fonts/e71599a7c939/fontawesome-webfont.woff2?v=4.4.0 is the path that was written to lib.css.

[magnars]

Yeah, I've got a fix in the works. :)

[zane]

Okay! This is helping me really understand the Optimus internals, for what it's worth.

[magnars]

I've released 0.18.2 with a fix for this issue. See the commit for more details. :)

[zane]

Aha!

[zane]

Thanks so much for the quick turnaround! 💖

[magnars]

No worries. Thanks for the repro repo - very helpful. :)

By the way, the Travis build failed just now - turns out clean-css has changed their API just the other day. I'm working on a fix for it.

[magnars]

0.18.3 released with the latest fixes.

[zane]

Fantastic.