-
Notifications
You must be signed in to change notification settings - Fork 211
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Updated Hyde-Hyde to use Hugo pipes for scss #45
Conversation
@jd4no many thanks for your time and the PR. A quick question though: Have you checked the issue with sourcemaps when using Hugo pipes? Last time I checked and used Hugo pipes, it messed up the sourcemaps badly (i.e. the generated CSS rules in the browser cannot refer back to the source SCSSs). I have tried both approaches, using Hugo pipes vs. using external tools, as written here in my blog: https://htr3n.github.io/2018/07/minimal-hugo-workflow and ended up with using Gulp to handle sourcemaps properly. The only caveat with external tools like Gulp, that I have not had enough time to solve, is cache busting. How's your experience? Cheers, |
Hey Huy,
I have been using the source maps generated by the patch I submitted and
they seem to be working fine. What I have noticed is that the initial page
load seems to refer to the generated css files (which are not usable), but
if you refresh the page they correctly point to the scss files and are
correct. I'm not sure why the initial load doesn't work. My guess would be
the issue could actually be with the dev tools not loading them correctly
until they are rebuilt while dev tools is watching. But again, after
refresh (not hot reload, but actual refresh) they seem to work fine for me.
…On Tue, Oct 9, 2018 at 6:36 PM Huy Tran ***@***.***> wrote:
@jd4no <https://github.com/jd4no> many thanks for your time and the PR.
A quick question though: Have you checked the issue with sourcemaps when
using Hugo pipes? Last time I checked and used Hugo pipes, it messed up the
sourcemaps badly (i.e. the generated CSS rules in the browser cannot refer
back to the source SCSSs).
I have tried both approaches, using Hugo pipes vs. using external tools,
as written here in my blog:
https://htr3n.github.io/2018/07/minimal-hugo-workflow and ended up with
using Gulp to handle sourcemaps properly.
How's your experience?
Cheers,
Huy
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#45 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AOWMW1mLb_nMAWPZuD6lzUpoYwA4_tiYks5ujTLigaJpZM4XSEam>
.
--
Joey Defourneaux
|
@jd4no that sounds great. I am on the move and will have a closer look. Btw, why don't you also add cache busting/finger printing into your suggested resource pipes? |
Hmm... Thats an excellent question. Honestly I just didn't think about it, but its a good idea. If you want I can resubmit with that change. |
Ok, I added in fingerprinting. I did not add concatenation since some of the styles are only included with conditionals. |
Updated Hyde-Hyde to use Hugo pipes for scss
Updated Hyde-Hyde to use Hugo pipes for scss
I updated the hyde-hyde theme to be able to use the scss files directly in development and into production with out needing an external preprocessor. This patch allows the css to be generated directly from the scss files using Hugo pipes. Only the called scss files will be added to the outdir static folder.
I also removed the now unused css and css.map files since these files will be generated at compile time.
This patch allows for faster development since the scss files are watched and recompiled directly when running
hugo server
as well as removing tech debt from needing to know that the theme's scss files need to be manually preprocessed into css.