If Iām reading the css.Build doc correctly, this could eliminate some or all of the reasons I currently use several PostCSS packages. Very interesting!
Also, if I can convince the ESBuild author (one of the 2 founders of Figma) to implement my proposal for ātree shakingā, this would be even more fantastic:
Hugo 0.158.0 packages
Brew - Hugo Brew package for macOS and Linux - updated 
Snap Package - Hugo Snap package for Linux - updated
Docker/CI Image - Hugo Docker image for Continuous Integration - updated
FreshPort - Hugo FreshPort package for FreeBSD - updated
Debian - updated
Ubuntu - not yet updated 
Fedora Copr - Hugo RPM package for Fedora and CentOS - not yet updated
Chocolatey Package - Hugo Chocolatey package for Windows
- traditional release - updated
- extended release - updated
Is css.Build entirely implemented within Hugo, or does it leverage something else?
My reason for asking is that Iām interested in moving away from Sass and leaning more on pure CSS. I got very interested in LightningCSS, which seemed to offer many of the things I thought Iād need to do this, but the only person who seemed to have dabbled in integrating Hugo and LightningCSS, @bwintx , appeared to have cooled on the idea.
If css.Build isnāt a skin over LightningCSS, how does it differ? Because it sounds like it offers most, maybe even all of what LightningCSS offers, starting with speed.
Whatever the implementation, it sounds like it could be just what Iām looking for. Thank you.
css.Build, as is true for the js.Build capability introduced in Hugo 0.74.0 nearly six years ago, relies on the Go-based esBuild bundler package.
@angusm, youāre right that I did back off from using Lightning CSS with Hugo after playing with the combination for several weeks (for a variety of reasons), but I agree with your assessment that the recent addition of css.Build is an excellent substitute for many of the powers, including the speed, that the Rust-based Lightning CSS offers.
Iām definitely excited by this. Because it looks as if it will make it possible for me to āun-Sassā and just write āpureā CSS (nothing against Sass, which Iāve found useful for years, it just seems that working with some elements of modern CSS, such as properties, gets a bit convoluted if you have to do it via Sass). And now css.Build is standard, Iāll be able to do that not just for personal projects, but also for stuff I intend to open-source in future.
By the way, @bwintx, thanks for your past blog and forum posts about LightningCSS, which I found very clear and helpful.
@angusm Since my last reply in this thread, Iāve done a little more research on this, and would now add that oneās choice comes down to a judgment call as to which CSS features one wants to handle via css.Build. The relevant esbuild documentation says:
. . . this is only concerned with syntax features, not APIs. It does not automatically add polyfills . . . Automatic polyfill injection is outside of esbuildās scope.
So that would rule out, e.g., using light-dark() ā a fix for which apparently would require a polyfill (although one GitHub issue filing in 2024 did request it, albeit with no response as yet from any esbuild devs).
I may address all this in a future blog post but, for now, thought Iād pass along what Iāve discovered on this specific aspect.
@angusm Have now published that additional blog post I mentioned re this subject:
I hope you, and others with similar questions and decisions to make, will find it useful.