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.
With the official GitHub JS client and @ltd/j-toml respectively.
As part of this, turn the JS files into modules and load the
dependencies from inside the modules.
A few places, links to various pages were still referred to as "wiki
pages", and there were even a few links still going to the actual LOOT
GitHub wiki (only one is fixed here, the other is in loot/loot…).
Oliver Hamlet
Oliver Hamlet
pStyl3andGitHub
Oliver Hamlet
Frederik “Freso” S. Olesen
WrinklyNinja