Our great sponsors
-
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
hugo-site
This is the repository from which the Hugo-generated version of https://www.brycewray.com is built.
-
-
-
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
Puts Debuggerer
Ruby library for improved puts debugging, automatically displaying bonus useful information such as source line number and source code.
While I was helping someone resolve an apparent problem with his own Hugo site, I saw that his chosen theme installed and employed Hugo through just such an approach. In this case, the npm package was Hugo Installer, created and maintained by Dominique Müller.
Like the more venerable, more popular, but (in my opinion) less suitable hugo-bin, Hugo Installer makes it easier to manage Hugo use in projects already making thorough use of Node.js packages — which seems to describe a huge majority of the projects you’ll find on places like GitHub and GitLab:
When run from a package.json script, Hugo Installer checks for the presence of a Hugo binary — by default, in the project’s bin/ folder, although you can pick a different location — and, only if it doesn’t find the binary, downloads and installs a version, which you must specify. The check goes very quickly and, thus, I suggest you make a package.json script that does only the Hugo Installer part, and use it with your other Hugo-related scripts. Here are some examples, some of which use Müller’s exec-bin package so the installed Hugo binary will run as you would expect:
This month, I took my site squarely into npm-ville when I brought in the npm version of Sass and added PostCSS to make "future" CSS work with current browsers. As it turns out, those changes made my site an unexpectedly appropriate target for the use case that Hugo Installer presents. I’m sure I’ll find nits to pick over time but, for now, I’m impressed by what I’ve seen.
Like the more venerable, more popular, but (in my opinion) less suitable hugo-bin, Hugo Installer makes it easier to manage Hugo use in projects already making thorough use of Node.js packages — which seems to describe a huge majority of the projects you’ll find on places like GitHub and GitLab:
During my years of using the Hugo static site generator (SSG), I’ve occasionally seen mentions about how you could install, and even run, Hugo’s Go-based binary by using one or more JavaScript packages sourced via npm. Having long ago understood the usual, very un-npm-ish Hugo methods for installation — much less the un-npm-ish nature of Hugo use in general — I never bothered looking into these JS-based alternatives. Besides, I figured, how could they even work? And, if they did, in what use cases did they make more sense than normal Hugo use?
During my years of using the Hugo static site generator (SSG), I’ve occasionally seen mentions about how you could install, and even run, Hugo’s Go-based binary by using one or more JavaScript packages sourced via npm. Having long ago understood the usual, very un-npm-ish Hugo methods for installation — much less the un-npm-ish nature of Hugo use in general — I never bothered looking into these JS-based alternatives. Besides, I figured, how could they even work? And, if they did, in what use cases did they make more sense than normal Hugo use?
Like the more venerable, more popular, but (in my opinion) less suitable hugo-bin, Hugo Installer makes it easier to manage Hugo use in projects already making thorough use of Node.js packages — which seems to describe a huge majority of the projects you’ll find on places like GitHub and GitLab: