I followed this tutorial to install Tailwind for Hugo (minus the creating a site part). Everything works well the past few months, but I have noticed that, sometimes when I change a Tailwind value, the site reloads but the class is not applied unless I cancel the build (ctrl+C) and then run npm run all (see the package.json part). I am not sure if it is due to Hugo’s cache or Hugo reloading before the CSS is applied by Tailwind. Do I need to add anything to the Hugo command’s part in the package.json to prevent this? I have tried hugo server --ignoreCache and hugo server --disableFastRender but both did not work in the cases I tested after running npm run dev.
Perhaps of help:
Didn’t help. I prefer my current setup. I just need to know if I need to add any flag to the hugo server command.
This isn’t something that a Hugo setting will fix. The part of my link which was applicable to your request — how you could get Tailwind CSS changes to appear during development — was based on the following article:
Note in particular the second major heading in there (“2. How to use TailwindCSS without external NPM scripts, just Hugo Pipes”), in which he explains:
To make [this] work in both production and development the “Hugo Way,” I came up with a little hack. Rather than using the input file as a regular CSS resource, we can tell Hugo to treat it like a template file using the
resources.ExecuteAsTemplatepipe.To ensure that the result always changes, we can create a random string and pass it into the CSS input template. Also, the final CSS file has the generated random string as part of its file name.
[Emphasis added.]
1 Like
Make sure you have all sources included, so TailwindCSS knows where to look.
I had similar issues, it fixed by this tailwind.config.js change:
From:
content: [
'./layouts/**/*.{html,js,md}',
],
To:
content: [
'./layouts/**/*.{html,js,md}',
'./static/**/*.{html,js,php}'
],
Depends of course where you keep files and what type of files you have there.
One thing you can try in package.json, switch from npx tailwindcss -i to npx tailwindcss-cli -i
I did that.
That breaks arbitrary values using @apply.
Didn’t help. I prefer my current setup. I just need to know if I need to add any flag to the
hugo servercommand.
No. Your issue is related to your current setup. If you change a Tailwind value it will take some time to recompile the styles, as the css is huge in dev, longer than the time it takes Hugo to reload the page.
Could be, but even the --disableFastRender flag didn’t help the last time I tried it. The setup I shared calls Tailwind first before Hugo, so it could be true what you are saying that subsequent reloads after the first build makes Hugo faster than Tailwind’s --watch flag.
Disablefastrender is just going to write your changes to disk, but that will still be faster (waay faster) than re-compiling Tailwind, any day of the week.
Simple to test though, does the first change appear a little later with subsequent changes, i.e. when Hugo rebuilds after your changes to Tailwind have finished?
Tbh, changing Tailwind values is not something I’d normally be doing in dev, as it takes so long. Normally it should not be required. Stop using @apply and I think your problem will go away, it’s not recommended; Tailwind is designed to be used as utility classes on html.
Actually, there’s a easier way to test.
In your package.json change "dev": "run-p dev:*", which runs dev scripts in paralell to "dev": "run-s dev:*" to run them sequentially. Hugo will then wait for Tailwind to finish compiling before building your site.
It usually happens periodically, e.g the last time it happened I added a new class I had not used before.
I prefer it that way to see changes in real time.
The issue occurs with inline classes, not @apply.
This breaks the dev:hugo part, so hugo server does not work in the build process.
That’s never going to happen if you are rebuilding tens of Mb of css every time.
Inline classes that ship with Tailwind, or those you are creating on-the-fly with @apply? I’m guessing the latter.
My CSS is only 29kb unminified. So, it doesn’t matter.
Yes.
After being built for production I imagine. Check your source in dev, I think you will find it’s a bit bigger than that!
It is not, but now we are deviating from the real issue I asked about. I will close this topic and try the solution by @bwintx instead.
1 Like
This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.