I have upgraded my site to use Tailwind 3 using This method.
When I run Hugo server with hugo server --templateMetrics --disableFastRender --verbose --templateMetricsHints, I can see that PostCss is running every time a file changes.
Even if it is a non-layout file like markdown.
Is there any way I can prevent that?
'cause right now it’s painfully slow.
Here’s an example repo.
Forked from @bep 's tailwind starter and modified to use the above method to use tailwind.
You can check the slow speed by running hugo server with --verbose flag turned on.
Hugo does monitor files and on change runs itself over the codebase. No it’s not possible to run postcss only when your styles change. Mostly because to create a page a stylesheet has to be created.
You could extract your style pipeline from hugo, run a monitor outside of hugo parallel to the hugo server, then compile changes to a stylesheet in static/mystyles.css with postcss when THAT monitor sees changes and then hugo will only copy this file over if it’s changed. Else it’s running every time.
If that takes extremely long, then have a look at why this is. If it’s just milliseconds you need to ignore that
Hugo does not support Tailwind 3 yet; If I read “that method” correctly, it updates the template with a new CSS url every time, which will certainly trigger a new build.
some plugins like tailwind forms etc doesnt work properly so I searched alot like you are doing and best recommendation is to stick with one of the above hacks until some official progress on this from Hugo
just to give you heads up do not expect anything soon as I see the integration issue with tailwind since 2020.
same here Hugo now take 15 seconds for the 3 pages I generate all internal simple markdown. but how long it takes not a problem unless you thinking to setup some automatic build then it will be a big problem in which case other ssg might win over Hugo or you have to choose between Hugo or tailwind.
tailwind % hugo server
Start building sites …
hugo v0.92.0+extended darwin/amd64 BuildDate=unknown
| EN
-------------------+-----
Pages | 3
Paginator pages | 0
Non-page files | 0
Static files | 0
Processed images | 0
Aliases | 0
Sitemaps | 0
Cleaned | 0
Built in 14585 ms
hope this was helpful
just a side note I am using Hugo Blist theme cant confirm if it has to do with the theme or Hugo but all my tailwind Hugo test projects ends up being slow. Hugo without tailwind seems to be really fast.
Sorry, I’ve added the repo link.
This is nothing new. It’s actually using the method proposed by @Jonas_D and modified by some comments from the GitHub issue linked
BTW thank you for sharing your experience.
I have seen that repository I though it was something new that you mentioned. that repository is not useful now with tailwind version 3.
Good news Mr. @Jonas_D have created an amazing new repository along with the previously published blog and my new site generation for 3 pages is only 4ms down from the previous 14,585ms when I was using Hugo blist theme.
% hugo server -D --watch
Start building sites …
hugo v0.92.0+extended darwin/amd64 BuildDate=unknown
| EN
-------------------+-----
Pages | 3
Paginator pages | 0
Non-page files | 0
Static files | 0
Processed images | 0
Aliases | 0
Sitemaps | 1
Cleaned | 0
Built in 4 ms
I think this is by far the best Hugo + tailwind 3 integration. have a good day and thanks alot @Jonas_D
A side note this new repository have no issues when I use tailwind forms or tailwind typography plugins works like magic
Hugo will stay “blazingly fast” with the pipe outside - or better, be blazing fast again. It won’t start copying stuff before the stylesheet is done. I read on their blog that you should for development use the CDN version of Tailwind, which probably doesn’t change with every tiny change to your content.
Usually i wouldn’t use the CDN version in development because it’s configuration is kinda awkward. BUT using Hugos powerful template magic, I could see myself writing an abstraction around this, so that it uses inline script tags in development and the regular tailwind.config.js in production. If you are worried about having a run-time dependency during development, this is not the best solution though.