CSS update requires changing hugo.toml?

[djsamperi]

I have found by trial and error that after updating cusom CSS (using hugo-book theme) the change is not rendered unless I modify and change hugo.toml. Starting the server with

hugo server --disableFastRender

does not change this behavior. More precisely, I update assets/_codeblock.scss and this is included in assets/_custom.scss. The change might involve changing the background color of codeblocks, for example, using pre.chroma tag. Sometimes I must delete browsing data in Google Chrome to see the change, but this is rarely the case.

[irkode]

maybe this one helps:

Hugo SASS pipelines do not recompile on updates in imported stylesheets

My SASS pipeline stopped working around the time GoHugo reworked it’s cache system earlier this year. Now all it does is acknowledging that a change was done in file x and reload, but it does not run the SASS pipeline again. I have to stop my Hugo server and start it again to have my changes processed. While this is an issue, I am about 50% tired of finding out what is going on and just living with it (it doesn’t take too much time to restart) and 50% thinking to move my stylesheet generation o…

[djsamperi]

Thanks, I tried inserting the [build] options suggested by bep, but it makes no difference. Updating a CSS file does not trigger an execution of the pipeline. This might be due to
the way the hugo-book theme is designed.

[irkode]

just found that one related to themes munts an cachbusters…with nice explanation

Using the new `cachebusters` feature with a theme

The example config in the 0.112.0 release notes and in the current version of the Hugo/Tailwind starter assumes a single CSS file located at the assets/css/ level. However, if I use a theme and have multiple CSS files in themes/[theme-name]/assets/css instead, what change should I make in the cachebusters setting for the CSS files? The Hugo dev server’s --debug mode reports no cachebusters matches when I edit a template while using the following: [[build.cachebusters]] source = "themes/[them…

so hugo version plays a role…and maybe hugo stats… and ofc your setup

[davidsneighbour]

I am a step further in my “investigation”. I have the feeling that it’s the use of @import vs @use in my SCSS that makes recent Sass versions ignore updates. Running my Sass system inside of Hugo results in a CSS file, outside of Hugo it fails with plenty of issues. I am reworking that and we’ll see if the Hugo server is updating then when I change files. It might be an issue in SASS instead of Hugo.

[djsamperi]

Ok, so I tried source = 'assets/.*\\.sccs', but it did not help.

There is some talk on that page about hugo server --debug, but
when I try this with hugo version 0.40.2 is fails complaining that --debug
is an unknown flag.

[djsamperi]

Changing @import to @use only caused more issues.
This is probably a theme issue.

[djsamperi]

The theme I’m using (hugo-book) places scss files in assets, but it seems Hugo takes assets/css as “root”. Copying the scss files to assets/css fixes the problem, provided this
is added to hugo.toml:

[build]
  [[build.cachebusters]]
    source = 'scss'
    target = 'css'