This site’s GitHub repository is now public! Thus, I am taking out the code blocks that were here, since otherwise they’d constantly be outdated compared to the current repo; instead, I will link to the appropriate parts of the repo. And, um, don't make me regret making the repo public, OK, Internet? Pretty please?
[I’ll keep the other updates in place, below, for archival purposes.]
Updating to include in
.eleventy.js the code from Pascal Widdershoven that makes possible, at long last, a simple way to automate linking to previous and next posts from within a single-post template, about which I’ll have a short post ASAP.
I am updating this primarily to conform to some fixes I made a few days after the original version of the post.
One thing I had noted was that, during development mode, Eleventy’s included Browsersync server was auto-refreshing the browser when I made textual changes, but not CSS/SCSS changes; for the latter, I’d have to do a manual refresh. Not terrible; just annoying. I then tried using webpack’s built-in server instead, but found the same issue as others, which was that it didn’t “see” Eleventy’s changes without, yep, manual refresh. What I finally tried was installing the Browsersync plugin for webpack, then setting Eleventy just to watch and not serve during development mode. Once I did a little tinkering with settings, that did the trick. Now, with the setup I have below—noted in
package.json— I get full and automatic browser refresh during development mode when I edit either text or SCSS.
And, yes, it was worth the trouble. Trust me.
As I mentioned, my process in making this happy transition was much easier than it might have been, thanks to the publicly available code from others who’d done it before me. Thus, I’m following their kind example by making this site’s GitHub repo public. What follows, then, is some explanation of which code does what.
A tale of three webpack config files
A lot of tutorials for using webpack will have you go through the motions of constructing a
webpack.config.js file, only to come in when things get hot and heavy and say, “Au contraire, sucker! Actually, you need separate configuration files for development and production.”
Not gonna pull that one on ya.
You can do it with just a
webpack.config.js file—one to rule them all, so to speak—but just about all the best-practices-kinda-stuff you’ll see says to set things up as follows, so that’s what I’m telling you, too:
webpack.dev.js—Contains only config code for development. Or, to put it another way: the code in this file is not intended for when you actually build your site on, say, Netlify. See my site’s
webpack.prod.js—You guessed it: this is the first file’s bro, except that this one contains only config code for production. See my site’s
webpack.common.js—Contains everything you’ll need for either production or development. The other two files merge this content when they’re run, thus ensuring everything happens as it should. Having this separate file, rather than duplicating code between the other two files, is DRY-friendly (well, maybe) and thus keeps peace among all of Babbage’s descendants, genetic or otherwise. See my site’s
Configuring Eleventy itself
eleventy.js, the main config file for Eleventy (thankfully, no separate
.prod versions here), see my site’s
eleventy.js file here.
By now, the more observant among you, having seen certain items mentioned in these files, may be wondering what’s in the
package.json file. Wonder no longer—although, I caution you, there are things in there I no longer use but simply haven’t gotten around to opening up a can of
npm uninstall on 'em as yet.
So, there you go. If you see anything in this site’s repo that’s helpful to your project, by all means, copy-pasta to your heart’s content. If nothing else, perhaps the
package.json file will give you some hints about cool npm packages to try if you, too, decide to weld Eleventy and webpack—which, I assure you, is a worthy endeavor.
You can call them whatever you want as long as each ends with a .js extension, but using names like these adheres sufficiently to standards-of-sorts that, when you look at other people’s code, you’ll probably find the examples more helpful than if you go into “Silly Walks” mode and call them fred.js, wilma.js, and pebbles.js, or somesuch. ↩︎