- It is a wee publishing system made of pipelined workflows, optionally driven by streams of file events (for the hotreloadin' bits).

- It will not surprise a Perl/PHP gentleperson hacker from the last century.

- It exists because one whistles silly tunes and shaves yaks.

  - my site maker's README

npm pack builds the file locally, then we expose it to the container filesystem where we do a build and check the outputs. You can move dependencies to bundledDependencies in npm to embed them in the image.

However, this is assuming you're rebuilding the static site generator itself every time. If you just want to build a site using an existing static site generator, it's much easier provided that the site generator itself is easy to use (for example, ours has a one-liner to take you all the way from nothing to a local static site running on localhost, see https://statue.dev)

If you aren't changing the SSG code itself between container runs you'd just mount the markdown to the container and pre-install the ssg in the Dockerfile itself. For statue.dev that would just be a Dockerfile almost exactly the same as the one we use already, except you'd use your own script, and RUN this in the Dockerfile itself: yes | npx sv create . --template minimal --types ts --no-add-ons --install npm && npm install statue-ssg && npx statue init && npm install

In your script you'd just npm run build then do whatever it is you want to do to send the files somewhere, and wherever starts the script, you'd do something like -v "pathtomymarkdown/foo:/test-package/" - not sure how to do this in github runners.

Depending on how interested you/other people are in doing this with statue.dev, we could prob get something like this (where the markdown is parameterized, not the npm package) working by Tuesday. We're building out the sandbox/build features on our cloud platform as we speak, this could be one of the first use cases/defaults.

The point being exactly to avoid whatever a third party may or may not deign to let me use, without hassle.

    pandoc -s README.md -o index.html

It's job is to help me make my website. Thus, its scope, (mis)feature set, polish will always be production-grade, where production is "works on my machine(s)" :)

Go for it, it's fun! I made one in TypeScript recently as a way to improve my skills there. Be warned though, completing one SSG may lead to wanting to start another haha.

I do somewhat wonder why not pandoc, but it is still an interesting project

  tree v2.1.1 © 1996 - 2023 by Steve Baker and Thomas Moore
  HTML output hacked and copyleft © 1998 by Francesc Rocher
  JSON output hacked and copyleft © 2014 by Florian Sesser
  Charsets / OS/2 support © 2001 by Kyosuke Tokoro

Why shell?

Well, not really because it’s portable, as despite being a “POSIX script”, most of the date and sed tricks I do don’t work on the BSD versions of those commands, with comrak, additionally, being a dependency.