I just started implementing the ToCSS pipeline and it works great on the first compile run with hugo server and just plain ol’ hugo. However, when I make changes to any of the scss files, the server prints Change detected, rebuilding site but doesn’t re-compile the css file.
**_
I maybe missing something in the docs (like a flag ? / brain fart?) Any help would be appreciated!
_**
I’ve tried various combinations below including deleting the /public directory and running hugo with no flags:
`hugo server --baseURL=https://MY_ACCOUNT.c9users.io/ --bind=0.0.0.0 --port=8080 --renderToDisk --disableFastRender --ignoreCache
Server Prints:
Watching for changes in /home/ubuntu/workspace/{content,themes}
Watching for config changes in /home/ubuntu/workspace/config.yaml
Serving pages from /home/ubuntu/workspace/public
I know I have it set for Hugo to create a fingerprint with the hugo cli command so I also tried removing fingerpring but the css file is still generated with a hash (the same hash too). Hence to why I added the ignoreCache. I thought there used to be a cleanCache flag??
NOTE:hugo -v returns nothing other than: WARN 2018/08/28 14:15:20 No translation bundle found for default language "en" and after deleting the generated site, I delete it and inspect the generated css file - There is no changes saved - so not related.
Sorry, not yet. I just started this project yesterday afternoon. However, I’m using the hugo-fresh theme. All I have done is change some images and been attempting to edit some scss when I ran into this issue.
I though of contacting the theme author but this seems more to as a Hugo pipeline/ToCSS procedure (on myside) than theirs(?).
Yes, could be good. It’s @lucperkins who made this theme. He’s very responsive and clear in his answers. Also take a look at this blog https://regisphilibert.com/tags/hugo/ from @regis. He wrote in detail about very important Hugo concepts and features.
I tested the Hugo Fresh Theme and it ran out of the box.
Thnx for getting back. I went ahead and contacted him (sent this thread link).
So does your build environment recompile the css file after making changes to any of the scss files within the /assets/fresh/partials/_*.scss ?? Can you verify please? Thank-you.
Oh, Thnx too for the link - I had it already opened in a tab - LOL
Well, no. Rebooting may have cleared Hugo’s cache because the changes took place only on the first run. I have to restart the server for Hugo’s pipeline to recompile the css. When running hugo after each scss change, the css gets recompiled. I would expect hugo serve would do the same.
@ Leo_Merkel So far I have verified that only running hugo after each change re-compiles the css. Running hugo server and hugo -w does not recompile. I was thinking this could this be a bug with v0.47.1, however, I reverted to v0.45 and this did not resolve the issue.
For resources.Get, the cache eviction strategy is to use the file’s extension. The common use case I’ve seen is resources.Get "main.scss" or something. That means that every scss Resource and their pipeline(s) will be reprocessed on any change of a file with extension .scss.
Also, I switched from a Linux machine to a Windows workstation to rule that out.
Next, I loaded up another theme: hugo-coder (on three different machines running on different operating systems as well) - Same-thing: Only re-running hugo EVERY TIME a SCSS change is made, initiates the pipeline.
So this REALLY has me stumped. Until someone here can come back and verify that this is not an issue (Not a machine | Theme issue across 3 themes now), I can only at this point think this is a Hugo specific limitation(?).
Thanks but, we would need to see your project’s configuration and file structure.
The themes’ repos (which I personally do not wish spending time investigating, maybe the theme coders do) are not of any help if the problem is on the Hugo level
Out of the box. No configuration changes. No file structure changes.
We cannot give access to anybody to our private git repos for security reason nor can anything be pushed to GitHub or Bitbucket due to out-bound restrictions and policies - (We are contracted with government entities).
I have, and two employees here tested this issue with three themes that utilizes the pipeline - out of the box, by; directly pulling the theme into an empty workspace (takes milliseconds), and immediately run the Hugo commands. The testing has been also performed on three different operating systems.
Iv’e been waiting for someone to verify the pipeline functionality on ANY theme on any system. Can you go in onto your development IDE for your https://regisphilibert.com site, run ‘hugo server’ or ‘hugo -w’, make a minor change to any of your SCSS files, and then verify that css file in the /temp or /public directory (depending on what command you used) was processed by the pipeline function and updated??
Thats all I am asking to follow Hugo’s protocol. Then we can determine to open an issue on GitHub or not.
Hi, it goes without saying I did not encounter the problem you mention on my website or any other projects I have worked on, otherwise I would know exactly what you mean and help you post the GT issue.
I did check again right now, just in case latest Hugo version had any effect here but either using hugo serve or hugo -w, the watch works and the main style file is rebuilt.
Would you: Create dummy project using the overall same configuration/file structure of your private project, replicate the issue there and then publish it as a public repo so we can take a look with our own machines.
Thanks,
PS: Your warning mentions a default language bundle which means you are in multilingual. What system are you using? Filename or Diretctory etc… A public repo replicating your project structure would answer many questions we do not even know enough to ask in the first place.
Seems the reason is the cache eviction strategy. Bulma is sass as in resources.Get while fresh mixes in scss. While rebuilt, the cache is not evicted. Really drove me mad.
I guess the cache eviction strategy need to build an import tree with some domain knowledge, or is that too much to ask? I mean there are sub/supersets of all kinds out in the wild with different file endings.
Yes, I think that is too much to ask in its general form. Note that it would maybe be possible to do in your particular case (I have not looked into it, but we do have an “import resolver” on the Go side (libSASS is a C++ library)), but I will assume that you could get into similar issues with other “Hugo Pipe” resources, and I’m not seeing how Hugo could ever build a general “import tree thing” that would work for SCSS, JavaScript, CSS … I don’t remember exactly how this is implemented, but I think it is by MIME type, so I suspect that this could be dramatically improved in a simple way by defining some simple eviction rules. If we say that SASS and SCSS is basically “the same thing”, so evict both. I’m not too worried about evicting too much as long as the cache works when I’m doing content edits etc.
Sounds like a 80/20 ^10 approach You’re right it’s driving nuts, as it’s a very obscure error. In my case, I even need to delete the _gen files and restart the server after it to truly replace the cached assets.
That doesn’t sound right, and I’m pretty sure that does not happen. Assuming you build with the extended version, we always do a full SASS build. I was talking about the “hugo server” behaviour.
You’re right it’s driving nuts, as it’s a very obscure error. In my case, I even need to delete the _gen files and restart the server after it to truly replace the cached assets.