Closed zane closed 9 years ago
optimus.assets.load-css/css-url-re
finds it just fine, which makes sense since it's rewriting the URL with the prefix.
Thanks, I'll take a look at it!
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
.
Yeah, I've got a fix in the works. :)
Okay! This is helping me really understand the Optimus internals, for what it's worth.
I've released 0.18.2
with a fix for this issue. See the commit for more details. :)
Aha!
Thanks so much for the quick turnaround! 💖
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.
0.18.3
released with the latest fixes.
Fantastic.
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.