Introductory note for the uninitiated: each entry in the “Gems in the rough” series is a collection of tips, explanations, and/or idle observations which I hope will be at least somewhat useful to those of you with websites built by static site generators (SSGs).
Some SSGs, such as Hugo and Jekyll, allow you to build your site without including posts to which you’ve assigned future dates. This can come in handy for any number of reasons, such as when you want to use multiple devices to work on a post and sync it through pushes to the site’s online repository.1 Although Eleventy doesn’t have an “ignore-the-future” capability out of the box, Saneef H. Ansari’s article, “Hiding posts with future dates in Eleventy,” describes an elegant way to add it. I even used it to “hide” this post until I was ready for you to see it.2 But . . . just be sure that, if your site’s config file includes the Eleventy documentation’s
html-minifier example code (as is the case for this site), you adjust it as suggested by David Soards or your builds will break with an error that includes the lyrical phrase,
outputPath.endsWith is not a function (TypeError). Fun stuff.
Acknowledgement: Thanks to Raymond Camden for the link to Mr. Ansari’s article!
It’s now been almost a year since this site began its “lurch” among various hosting vendors after having been on Netlify from the beginning back in September, 2018. In no particular order, I’ve used Render, Firebase, Cloudflare Workers sites, Cloudflare Pages, and even Netlify once again, albeit briefly. However, none of them can quite hold a candle to Vercel, the vendor to which I’ve most usually entrusted the site since the initial break with Netlify. I wish Vercel’s Edge Network had a lot more points of presence around the world and that Vercel hosting was easier to configure for things like HTTP headers3 but, those items aside, the unmatched speed and granite-like solidity of Vercel’s build process make it the top dog in the group and keep me coming back.
Not since the late 1990s has it been “cool,” or so it’s seemed, for companies to promote their websites’ URLs with the “www” upfront. They just say, “Visit [whoever].com,” and let it go at that. Perhaps influenced by that, I originally linked to this site only as “brycewray.com.” However, it turns out there are sound technical reasons to use the “www” in there, too (and Vercel agrees for its own network-specific reasons), so I’ve adopted that practice. Indeed, I have whichever hosting vendor I happen to be using at the moment use “www.brycewray.com” as the primary location to which all “brycewray.com” traffic is redirected, rather than vice versa as I formerly did. I also now include “www” in each page’s canonical URL as specified in the
head section of its HTML.
The latest version of Hugo, 0.84.0, emerged on June 18, with what the linked article described as “several configuration fixes and improvements that will be especially useful for themes.” It also updates the included goldmark Markdown parser version to 1.3.8. What it doesn’t do is fix any of the three problems that I noted in the most recent edition of this “Gems in the rough” series:
- Incompatibility with the JIT mode in Tailwind CSS 2.1+.
- Using the deprecated LibSass rather than Dart Sass for Sass/SCSS support.
- Punctuation glitches in goldmark.
Mainly due to the first two, I have temporarily ceased updating my two Hugo starter sets, one of which would benefit greatly from Tailwind’s JIT mode while the other would be better with Dart Sass rather than LibSass. Mind you, I harbor no illusions that the Hugo community will be broken-hearted by this decision. Still, when things change on either of these fronts, I’ll act accordingly.
As for the third issue, I have no expectation that it will be resolved; I don’t think the goldmark dev is interested in fixing it. The only alternative seems to be reverting to the blackfriday parser, which goldmark replaced in Hugo 0.60.0, but I can tell you that it’s not a foolproof fix even if we could assume Hugo will continue to support blackfriday indefinitely—which we can’t, because it won’t. For one thing, my recent tests show that using blackfriday with the current version of Hugo can result in occasional weirdness (e.g., a footnote numbered 0 which wasn’t even the first footnote in the document). Would using it with, say, a version prior to 0.60.0 allow blackfriday to work properly? Perhaps. But Hugo’s added many enhancements since the pre-0.60.0 days. I’m not going to tell the starter sets’ potential users to give up those goodies just for the proper punctuation that goldmark is incapable of providing.
Of course, that won’t obscure the presence of a “future” post on a site repo that’s public, as is this site’s repo: if people are so inclined, they can find it. In other words, don’t act as if a “future” post pushed to a public repo is truly hidden. It’s not. If you must push a “future” post to the repo but keep the post out of view until it’s not “future” any more, you’ll have to make the repo private. ↩︎
Don’t get me wrong: the process actually isn’t that hard. The issue I have in that regard is that it doesn’t appear possible to set a Content Security Policy for only the site’s web pages and not for its static assets as well (i.e., to avoid “Best Practices” gripes from Lighthouse), while such is possible with Cloudflare Pages through use of a Cloudflare Worker as I noted in “Headers up.” And, yes, I have asked—in the Vercel “Discussions” section on GitHub and on Stack Overflow. ↩︎