Repo for brycewray.com

This is the repository from which the Eleventy- and webpack-generated version of brycewray.com is built.

Not a starter kit, but . . .

While this is the actual site’s repo rather than a starter version thereof, you can turn it into the latter by doing the following:

Clone it to a local repo.
Make appropriate changes to the _data directory’s files.
Delete from src the Markdown files and images (well, maybe you should keep one or two of each around at the start, until you see how things work).

I chose to build this site with Nunjucks templates after converting its content from the Go-based Hugo and the React-based Gatsby; but Eleventy itself is extremely flexible in that regard, so go with what you prefer. [If you‘re interested in JavaScript templates (.11ty.js), I strongly suggest you check the amazingly well-documented example of Reuben Lillie‘s site.]

What’s under the hood

This isn’t a complete list but, rather, covers only the biggies. Check out package.json for the whole shebang.

Eleventy and webpack, of course, outfitted with a number of plugins that are probably self-explanatory once you see them in package.json.
lazysizes (and several of its plugins), responsive-loader, and a variety of imagemin-related items for processing the few images on the site.
typefaces, through which I’m using the Public Sans Web “font” for all non-code text and Roboto Mono for code and code blocks.
Browsersync—Although Eleventy comes with Browsersync for Eleventy-only use (i.e., if you weren’t using it with a bundler, as I am here with webpack), I use a separate Browsersync instance for the testbuild script (see “Scripts in package.json”). Note: I have Browsersync’s usually-on ghost mode turned off because it creeps me out 🙂 when I’m testing locally; you, however, might prefer the default “on” setting.
PostCSS for, among other things, transpiling my CSS for easier consumption — even for obsolete browsers (looking at you, IE).

Scripts in `package.json`

test—The standard script that comes with an npm init; I just leave it there even though I never use it. YMMV.
clean—Used in several other scripts to delete the _site directory on each run (dev or production), so you’re always looking at the latest.
start—This is the basic dev mode command (npm run start). It deletes site and then runs the next two scripts together in parallel.
dev:eleventy—Tells Eleventy this is dev mode and to check constantly for changes to content that it handles—which, in this config, is only the template material and Markdown.
dev:modewebpack—Tells webpack this is dev mode, for which it should use webpack.dev.js (as well as, always, webpack.common.js), and to check constantly for changes to items that it handles—which, in this config, are CSS and JS.
build—This is the basic production mode command (npm run build) and is what I set Netlify to use in deploying from _site. This script deletes _site and then runs the next two scripts in parallel. There’s no server functionality here, since this is just for production mode. (For an alternative that lets you check production build quality during dev mode, see testbuild further down.)
prod:eleventy—Tells Eleventy this is production mode and to output files to _site.
prod:webpack—Tells webpack this is production mode, for which it should use webpack.prod.js (as well as, always, webpack.common.js).
bsprod—See the next item, testbuild.
testbuild—This may be overkill, but I don’t want to have to deploy to Netlify to see whether there are notable differences between what I get in dev mode and what I get in production mode (I found that happened when I was getting accustomed to PurgeCSS, which I have since ceased using because I got tired of having to tell it to ignore needed code). Thus, this script works like the build script but also uses bsprod to run a separate instance of Browsersync to let you view it in your dev environment, whereupon you can confirm that everything’s fine before actually deploying to your hosting platform. Obviously, this is not for actual production (e.g., never make this the build command on that hosting platform). As you can suspect, this can tax your local computer pretty heavily; the more cores and RAM you can throw at it, the better.

Questions?

I don’t claim to be an expert on any of this stuff—as even a casual reading of the site itself, not to mention this repo’s contents, probably will demonstrate pretty quickly—but, if you have any questions about this repo, create an issue or contact me via either Twitter or email. I can’t promise the answers will be that great, but I’ll do my best to help. Others have helped me greatly in my attempts at site-building, so I want to “pay it forward,” as the saying goes.

Interested in other SSGs?

For those interested in other static site generators, I have also created Gatsby- and Hugo-based versions of this repo which also are now public. For more information, see “Different modes for different code.” As for the repo links themselves: