Why doesn't piping to postCSS behave like ToCSS when not using Hugo extended?

support
1

I have a theme using a fairly standard pattern to include CSS processed with PostCSS.

{{- if .Site.IsServer -}}
{{ $postcssed := resources.Get "css/main.css" | postCSS }}
<link rel="stylesheet" href="{{ $postcssed.Permalink }}">
{{- else -}}
{{ $postcssed := resources.Get "css/main.css" | postCSS | minify | fingerprint }}
<link rel="stylesheet" href="{{ $postcssed.Permalink }}">
{{- end -}}

So no minification/fingerprinting while in server mode during development, but otherwise does. Works fine.

I’m setting up git-push-to-deploy on my server and want to do a server side build (to allow for future on server content edits) but not have to check node_modules are installed and up to date. But how to work this?

An only commit hugo output approach won’t allow for server side edits, so that’s not workable.

I’ve seen posts elsewhere on the forum suggesting that generated resources are committed to git and normal hugo used on the server instead of hugo-extended, and that seems to work for SASS based processing.

It doesn’t work for PostCSS however because normal hugo happily processes Postcss resources (with node_modules installed of course). So it always errors with ‘module not found’.

So what feature am I missing in the docs that will allow this to work?

EDIT to add:
For now I’m running node on the server. My git post-receive script runs ‘npm i --no-save’ to keep node_modules up to date without altering package-lock.json.

2

We look for the postcss binary in 1) node_modules/postcss-cli/bin/ or 2) PATH … If not found we fall back to cached resources (if found).

2 Likes
3

Ah, thanks. I expect 2) was my problem, globally installed postcss-cli would have been in the path. I presume normal Hugo (non-extended) behaves the same way. Will experiment.