Fall back to trying ex.New(binaryName, cmdArgs...) when ex.Npx fails for PostCSS etc.

[kurotych]

I want to use a theme (https://github.com/google/docsy) but I don't want to install any NodeJS garbage on my host machine.

As a workaround, I created a Dockerfile, wrapped script and rebuilt hugo

FROM node:20-alpine

WORKDIR /usr/src/app

RUN npm install -g postcss postcss-cli autoprefixer

CMD [""]

docker build -t postcss .

❯ cat postcss

#!/bin/bash
docker run --rm -i postcss postcss "$@"

Rebuild Hugo with a changed next-line because Npx function adding the npx prefix that I don't need.

hugo/resources/resource_transformers/postcss/postcss.go

Line 203 in ee26e69

cmd, err := ex.Npx(binaryName, cmdArgs...)

=>

ex.New(binaryName, cmdArgs...)

It'd be nice to have a configurable binary path to the postcss to make it possible to call without npx prefix.

[almereyda]

I'm experiencing a similar drawback when working from within this dev container.

{
  "name": "Build environment",
  "image": "mcr.microsoft.com/devcontainers/base:bullseye",
  "features": {
  "ghcr.io/devcontainers/features/git:1": {},
    "ghcr.io/devcontainers/features/go:1": {},
    "ghcr.io/devcontainers/features/hugo:1": {
      "extended": true
    },
    "ghcr.io/devcontainers/features/node:1": {}
  }
}

postCSS filters are not applied and main.scss does not build a main.css file.

[cjshearer]

I ran into this myself. I can't use the postcss-cli package from nixpkgs, because resources.PostCSS shells out to npx to run postcss. An easy fix would be to make hugo's calls for npx binaries fall back to checking the user's PATH for binaries by the same name - it would be backwards compatible and afaik would follow hugo's security model.

An aside:
I'm curious what @bep's plan is for the new tailwind oxide engine. The only reason I have a package.json with

  "devDependencies": {
    "@fullhuman/postcss-purgecss": "^5.0.0",
    "@tailwindcss/typography": "^0.5.13",
    "autoprefixer": "^10.4.19",
    "postcss": "^8.4.38",
    "postcss-cli": "^11.0.0",
    "postcss-html": "^1.7.0",
    "tailwindcss": "^3.4.4"
  },

is because of tailwind. Once we get the new tailwind engine, I expect it will warrant its own resource_transformer. I realize @kurotych, @almereyda, and I are the 1% of the 5% who care, but I'm hoping it won't depend on npx; I could ditch the whole npm/nodejs toolchain.

Related discussion:

• Add exec shortcode #796
• Bundle Dart Sass into Hugo installation process #8299
• Add a concept of HUGOBIN and a way to install binary dependencies #10757
• https://discourse.gohugo.io/t/add-a-way-to-import-npm-modules-as-hugo-modules/43878/2
• https://discourse.gohugo.io/t/hugo-pipes-and-tailwind-s-upcoming-oxide-engine/47802

[bep]

I'm curious what @bep's plan is for the new tailwind oxide engine.

Odd timing, I was just testing Tailwind Oxide:

bep/hugo-starter-tailwind-basic#19

It's convenient to have npm install and maintain the version of this stuff, but if we could get rid of PostCSS for TailwindCSS, that would be pretty great. A first glance it looks like the Tailwind CLI lacks some options in this area, but that could be fixed.

As to this issue:

It'd be nice to have a configurable binary path to the postcss to make it possible to call without npx prefix.

Hugo currently only executes predefined binary names that's in the OS PATH. Having a way to execute arbitrary binaries (even if that could be controlled) is not something I'm opening up for. We could/should probably have a useNpx or something, but I'm not sure where to put it.

[bep]

❯ cat postcss

Why not create a npx wrapper that do similar?

[cjshearer]

I don't want to speak for @kurotych, but given that they are already building and running a docker container with a postcss shellscript, adding an npx wrapper doesn't seem like much of an additional lift.

However, I think both of our problems would be solved easily and securely by falling back to checking for a binary of the same name using ex.New(binaryName, cmdArgs...), when the following fails:

hugo/resources/resource_transformers/postcss/postcss.go

Lines 203 to 210 in af0cb57

	cmd, err := ex.Npx(binaryName, cmdArgs...)
	if err != nil {
	if hexec.IsNotFound(err) {
	// This may be on a CI server etc. Will fall back to pre-built assets.
	return &herrors.FeatureNotAvailableError{Cause: err}
	}
	return err
	}

Basically:

1. check if postcss exists with npx (already done)
2. failing that, check if it is installed globally

[bep]

However, I think both of our problems would be solved easily and securely by falling back to checking for a binary of the same name using ex.New(binaryName, cmdArgs...)

I agree. I'm going to repurpose this issue some something that's both simple and actionable, and if that does not fix it, we'll revisit later.