It's currently easy to hit the GitHub API's rate limit just by refreshing the credits page a couple of times. The data doesn't change that frequently, so instead fetch it into a JSON file as part of the build process, have Hugo generate the page using the JSON file and a template, and deploy the site each day at midnight so that the live data is at most 24 hours old.
Use NPM to manage their versions: manually vendoring the libraries isn't feasible for Octokit, as its libraries aren't provided as single-file imports, and have nested dependencies of their own. Since NPM is needed to resolve that, use it for the other dependencies too.
Hugo's built-in bundling and minification support is used, though it means that the dependencies are duplicated within the scripts imported on different pages. I think that could be avoided by introducing a middle layer of JS assets that bundle the dependencies but aren't bundled themselves.
Hugo is a lot easier to work with locally (especially on Windows), and
because it's not natively supported by GitHub Pages, it gets deployed
using GitHub Actions, so it's also easier to keep the version of Hugo in
sync between local builds and deployments.
I've compared the generated _site/ and public/ folders and they look
equivalent, except that Hugo also generates a sitemap: that can be
disabled, but it's good to have.
Jonathan FeenstraandCopilot
Oliver Hamlet