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).
Native lazy-loading: a surprise
A few days ago, I played around with my image-handling shortcode in an attempt to make it not require JavaScript on the client side. What I’d intended was to substitute the native lazy-loading in modern browsers for what I’d been doing with Andrea Verlicchi’s superb vanilla-lazyload script. However, I learned to my great surprise that even native lazy-loading still requires JavaScript! (H/t to this comment in response to a dev.to article.) As a result, I decided to let things be, continuing with vanilla-lazyload for JavaScript-enabled browsers and a noscript-prescribed normal loading process for the remaining tiny percentage of JavaScript resisters1 out there in WebLand.
The Slinkity project
The Eleventy SSG is nearing the release of version 1.0.x, and with that release will come full support for the intriguing Slinkity plugin. Slinkity, the brainchild of Ben Holmes, is still in early development but its promise is enormous. The part of it I find most compelling is that it will allow the addition of components from the React, Vue, and Svelte frameworks, which is likely to make the already formidable Eleventy an even better match for many projects where it might otherwise have been found wanting. Keep an eye on Slinkity. It could be a game-changer.
Cloudflare Pages: the glitches continue
Update, 2021-10-03: I learned today that the problem I note below was due to an incompatibility between the recently released version 9.x of the postcss-cli package and any Node.js version prior to 12.20. The usual way you get around that when building to your hosting vendor of choice, assuming it’s using a Node.js version that fits this qualification, is to add a NODE_VERSION environment variable set to at least 12.20.0. (Consult your respective vendor’s documentation for details.) In my site’s case, I am currently spec’g 14.16.0 since that conforms to the Node version I run locally. Finally: despite my having learned this, I’ll leave the remainder of this part of the article as it was for the sake of transparency.
Until yesterday, I had used Cloudflare Pages (and, with it, the Cloudflare CDN) to host this site, off-and-on, for a while. I’ve written in the past about the technical challenges of this still-new platform, particularly where build times are concerned; but, yesterday, the problems reached a new, show-stopping level.
I have multiple Eleventy repositories (including this one), with differing build scripts, which CFP had handled just fine before yesterday morning but which, starting then, errored out on each CFP build attempt with cryptic messages regarding an ES modules (ESM) loader:
12:24:22.053 (node:1650) ExperimentalWarning: The ESM module loader is experimental.
12:24:22.086 internal/modules/run_main.js:54
12:24:22.086 internalBinding('errors').triggerUncaughtException(
12:24:22.086 ^
12:24:22.086
12:24:22.086 Error [ERR_UNSUPPORTED_ESM_URL_SCHEME]: Only file and data URLs are supported by the default ESM loader
12:24:22.086 at Loader.defaultResolve [as _resolve] (internal/modules/esm/resolve.js:720:11)
12:24:22.086 at Loader.resolve (internal/modules/esm/loader.js:97:40)
12:24:22.086 at Loader.getModuleJob (internal/modules/esm/loader.js:243:28)
12:24:22.086 at ModuleWrap.<anonymous> (internal/modules/esm/module_job.js:42:40)
12:24:22.086 at link (internal/modules/esm/module_job.js:41:36) {
12:24:22.086 code: 'ERR_UNSUPPORTED_ESM_URL_SCHEME'
12:24:22.086 }
12:24:22.104 npm ERR! code ELIFECYCLE
12:24:22.104 npm ERR! errno 1
12:24:22.106 npm ERR! eleventy_site@ prodpostcss: `postcss _site/css/$(cat csshash) -o _site/css/$(cat csshash)`
12:24:22.106 npm ERR! Exit status 1
12:24:22.106 npm ERR!
12:24:22.106 npm ERR! Failed at the eleventy_site@ prodpostcss script.
12:24:22.106 npm ERR! This is probably not a problem with npm. There is likely additional logging output above.
This behavior began after yesterday’s worldwide incident with Let’s Encrypt SSL certificates. Since that was Let’s Encrypt’s problem, not Cloudflare’s, it may have been totally coincidental that my post-cert-glitch build attempts failed. All I know is that, once the problem started, repos which still build just fine on Netlify, Vercel, Render, and Digital Ocean App Platform would no longer build on CFP. Cloudflare personnel to whom I conveyed word of this via Discord said the fault must lie in my package.json scripting, rather than their platform, but those other vendors’ successful builds (about which I’ve notified a Cloudflare employee) would seem to suggest otherwise.
Whether any of this is applicable to you, I have no idea; I’m just tossing it out there for your consideration before you rely on CFP, a platform which remains both highly interesting and aggravatingly glitchy.
Note: Ironically enough, when I first tried to issue this post, Vercel (to which I’d reverted yesterday after the aforementioned CFP issues) was having a system-wide outage of its API and dashboard which, you guessed it, prevented the site build. Ya can’t win.
Update, 2021-10-02: Today I tested Cloudflare Pages again and found that, by deleting my previous setups there and restoring them, the errors stopped. I have no idea what happened, but scripts that failed as noted above are now working fine. Weird. Anyway, I moved the site back to Cloudflare to take advantage once again of this vendor’s superior CDN.
To be fair, I’ll note that there are some corporate users who would gladly use JavaScript in their browsers if only their IT departments didn’t lock them down to such a preposterous extent. ↩︎
Latest commit (4c23918b) for page file:
2023-03-05 at 10:40:50 PM CST.
Page history