HUGO

Postprocessing sample - could it be optimized?

Hello Hugo people!

So I was glancing over the documentation of post-processing in the hopes to finally get purgecss running and realised that something seems off with the sample:

{{ $css := resources.Get "css/main.css" }}
{{ $css = $css | resources.PostCSS | minify | fingerprint | resources.PostProcess }}
{{ $css.RelPermalink | upper }}

This will MINIFY the full css, then FINGERPRINT, then run POSTCSS which will purge unused css rules from the minified and fingerprinted stylesheet.

Am I misunderstanding something or is this a little bit of overkill? Shouldn’t be the order

  • remove unused parts
  • minify
  • fingerprint

so we don’t do any work on stuff that will be gone anyway in the end? Mostly because my inner mantra tells me “DO NOT TOUCH IT after fingerprinting”.

But maybe I am missing something procedural here?

* PS: Fingerprinting is not being used at all in the sample. It just runs and no attribute is added to the stylesheet link.

although resources.PostProcess at the end of pipes, i believe it’s actually only tell Hugo to delay the transformation.

The real transformation chain is only this part resources.PostCSS | minify | fingerprint.

  1. resources.PostCSS (including purgeCSS)
  2. minify
  3. fingerprint

So it’s already in correct order as your post above.

1 Like

Ok, so the documentation needs to be written more dum-(me)-compatible :slight_smile:

resources.PostProcess delays any transformations to after the build

You cannot manipulate the values returned from the resource’s methods.

That’s why the fingerprinting example is provided, along with the phrase

this example will not work as expected.

A warning (note) in the documentation describing what not to do, and why not to do it, is probably better than a negative example.

Hmm. No. I am a big fan of NOT showing what NOT to do. It’s good to say “doing that won’t work” but adding a whole example of something that won’t work is wrong. Also: The last sample again uses fingerprint. On the other side if it’s kept until postprocessing is done that’s ok then.

A warning here, in my view, is crucial to avoiding an error that might take a while to track down if one doesn’t immediately comprehend the ramifications of deferred processing.

In our pipelines we are accustomed to toCSS | minify | fingerprint then writing the the <link> element with a cache-busting fingerprint and an SRI attribute. Neither the fingerprint nor the SRI attribute will be correct if the pipeline is deferred.

1 Like

I was believing that, but now I am not so sure anymore about this. I added post processing on a site of mine, still keeping the sri parameters in and it does not throw errors in the browser console, but maybe I am doing it wrong or missing something… I am also not sure if it removes anything in the css, hehe. The only thing I am sure of is that the postprocessing is being done - or called - (by dropping a {{- warnf "Going into PostProcessing" -}} in that with rule).

It’s weird. If you like to dive in, have a look at these two commits:

I am pretty sure I am doing something wrong. It’s too convoluted.

Yeah, me too. I was thinking about this last night, and realized that my testing has been insufficient to thoroughly understand the pipeline, primarily because I have always pruned post-build.