Zach Leatherman

Eleventy is now Build Awesome

2026-03-06T06:00:00Z

The Eleventy project is taking up the Awesome banner. To support the project, please sign up to get notified when our Kickstarter campaign launches!

State of the Browser 2026

2026-02-28T06:00:00Z

This is an event post. My individual talk page is here:

Get your tickets while they last!

An Official* Logo for HTML

2026-02-19T06:00:00Z

*Not official.

I was working on my slide deck for the upcoming State of the Browser conference and ran into what I would classify as a recurring issue: HTML needs a logo. There isn’t a broadly accepted official logo for (version-independent) HTML. There is a logo for HTML 5, but that versioned marketing term has long fallen out of regular use (and was introduced 18 years ago).

This is a community solved problem in both the CSS and JavaScript spaces!

CSS: , relevant discussion on CSS-Next.
JS: , relevant discussion on voodootikigod/logo.js.
HTML 5: , more info on w3.org.

I wish the classic orange badge hadn’t included a version number, but alas.

Anyway, I very quickly threw my hat into the ring and immediately recognized a much better option from Sam Stephenson sls.name that I’ll be considering canon moving forward (and hopefully this blog post puts some weight behind it for others too).

Here’s what it looks like rendered in your web browser:

HTML

I love the nod to the classic unvisited link color and the heavy outset border that doubles as angle brackets with the right head tilt.

If you’re interested in the source code, the HTML-only (copy-paste friendly) source code is included below (and also on Codepen):

<a href="https://indieweb.social/@sstephenson/116098428280403793" style="all:initial;cursor:pointer;font-size:2rem;width:4em;height:4em;color:blue;text-decoration:underline;display:flex;align-items:center;justify-content:center;background:#ccc;border:.5em outset #aaa;font-weight:900;">HTML</a>

How Eleventy Survived: Funding, Growth, and Open Source Reality

2026-02-03T06:00:00Z

Eleventy started as a side project. Now it’s a critical infrastructure for thousands of websites.

TL;DR: Open source isn’t broken. But the way we fund it often is. Let’s talk about what actually works.

In this episode, we sit down with Zach Leatherman, creator of Eleventy (11ty), to talk honestly about what happens after open source succeeds. From nap-time coding and nights-and-weekends maintenance to venture capital pressure, burnout risk, and the reality of funding long-lived developer tools, this conversation digs into the cultural and financial tradeoffs behind modern open source.

We cover sustainability, community expectations, funding models that don’t rely on hockey-stick growth, and why “free forever” only works if the people behind the project can stay whole humans.

Listen in: How Eleventy Survived: Funding, Growth, and Open Source Reality

Also on:

Eleventy, 2025 in Review

2026-01-12T06:00:00Z

A look back at the 2025 highlights for the 11ty org and the Eleventy project!

It was another huge year for 11ty. We shipped 177 releases (73% more than 2024) across the full 11ty/* suite. We closed 804 issues (15% more than 2024). We reduced core’s dependency count by 28% and weight by 22%. More folks are building with Eleventy than ever: our year-over-year npm downloads (for only core) are up by 51%!

No more tokens! Locking down npm Publish Workflows

2025-12-04T06:00:00Z

With the recent spate of high profile npm security incidents involving compromised deployment workflows, I decided that it would be prudent to do a full inventory of my npm security footprint (especially for 11ty).

Just in the last few months:

November 2025: Shai Halud v2 (PostHog) (and PostHog post-mortem): Worm infected ×834 packages. Propagated via preinstall npm script.
September 2025
1. Shai Halud (@ctrl/tinycolor, CrowdStrike): Worm infected ×526 packages. Propagated via postinstall npm script.
2. DuckDB: targeted phishing email (with 2FA) pointed to fake domain npmjs.help. Compromised packages were published with token created by attacker.
3. debug and chalk: same as above: targeted phishing email (with 2FA).
August 2025: S1ngularity (Nx) (and Nx post-mortem): well-meaning but insecure code (from approved authors) was merged which allowed arbitrary commands to be executed via content in Pull Requests to the repo. Compromised packages were published via a stolen NPM token.

Expand to see the insecure YAML from the S1ngularity attack

# Some content omitted for brevity
on:
  pull_request:
    types: [opened, edited, synchronize, reopened]
  # …
jobs:
  validate-pr-title:
    # …
    steps:
      # …
      - name: Create PR message file
        run: |
          mkdir -p /tmp
          cat > /tmp/pr-message.txt << 'EOF'
          ${{ github.event.pull_request.title }}

          ${{ github.event.pull_request.body }}
          EOF

      - name: Validate PR title
        run: |
          echo "Validating PR title: ${{ github.event.pull_request.title }}"
          node ./scripts/commit-lint.js /tmp/pr-message.txt

Given the attack vectors of recent incidents, any packages using GitHub Actions (or other CI) to publish should be considered to have an elevated risk (and this was very common across 11ty’s numerous packages).

I’ve been pretty cautious about npm tokens. I have each repository set up (painstakingly) to use extremely granular tokens (access to publish one package and one package only). This limits the blast radius of any compromise to a single package and has helped manage my blood pressure (I accidentally leaked a token earlier this year).

Security Checklist

I’ve completed my review and made a bunch of changes to improve my security footprint on GitHub and npm, noted below. The suggestions below avoid introducing additional third-party tooling that may decrease your footprint short-term (while actually increasing it long-term).

Caveat: my current workflow uses GitHub Releases to trigger a GitHub Action workflow to publish packages to npm (and this advice may vary a bit if you’re using different tools like GitLab or pnpm or yarn, sorry).

Use Two-Factor Authentication (2FA) for both GitHub AND npm, for every person that has access to publish. This is table-stakes. No compromises. Require 2FA everywhere.
- On GitHub, go to your organization’s Settings page and navigate to Authentication Security. Check the Require Two-factor authentication for everyone and Only allow secure two-factor methods checkboxes.
- npm requires you to specify this on a per-package basis that I describe in the Restrict Publishing Access section below.
When logging into npm and GitHub, use your password manager exclusively! Never type in a password or a 2FA code manually. Your password manager will help ensure that you don’t put in your credentials on a compromised (but realistic looking) domain.
- Would you know that npmjs.help was a spoofed domain? Maybe on your average day, but on your worst day? When you didn’t sleep well the night before? 😴
Review GitHub users that have the Write role in your repositories (Write can create releases).
Find any repositories using NPM tokens and delete the tokens in the settings for both GitHub and npm. We’re moving to a post-token world.
- Success criteria is having 0 Access Tokens listed in your npm Settings (granular or otherwise).
Switch to use Trusted Publishers (OIDC) in the Settings tab for each npm package. This will also setup the release to include provenance as well (which is great).
- This scopes your credentials to one specific GitHub Action (you specify which file to point to in .github/workflows/) and allows you to remove any references to tokens in the GitHub Actions YAML configuration file.
- The big goal here for me was to completely separate my publish workflow and credentials and disallow any access to those credentials from other workflows in the repository (usually unit tests that run on every commit to the repo). You could also use GitHub Environments to achieve this. This limits the blast radius from worm propagation (via postinstall or preinstall) to publish events only (not every commit), which is far more infrequent.
Restrict npm Publishing Access in the Settings tab for each npm package. Use the Require two-factor authentication and disallow tokens (recommended) option. Death to tokens!
Check in your lock file (e.g. package-lock.json for npm). This is especially important when using a release script that uses npm packages to generate release artifacts. Use npm ci instead of npm install in your release script.
GitHub Actions configuration files should pin the full SHA for uses dependencies (e.g. eleventy-plugin-vite). I learned that Dependabot can update and manage these too!

Other good ideas

Given the above changes, I would consider the following items to not to be of immediate urgency (though still recommended).

GitHub: Enable Immutable Releases preferably at the organization level. This will ensure no one can change tags and release contents after a release has been shipped.
Use a package manager cooldown.
- Added the cooldown option to my Dependabot configuration (direct link to dependabot.yml). This updates production dependencies weekly, now with a 7 day cooldown.
- I usually use npm-check-updates for local package.json file maintenance. It has a cooldown option too!
- npm install does have a --before option to pass a Date that can be used similarly (though isn’t relative).
- More on socket.dev: pnpm 10.16 Adds New Setting for Delayed Dependency Updates

Reduce dependencies! Every third party dependency has some risk associated with it, as you’re inheriting a bit of those developers’ security footprint too. It’s worth noting that the work being done by the folks at e18e to reduce dependency counts is making great headway to improve the ecosystem at large. You can do this in your own projects! I’m proud of the work we’ve done on @11ty/eleventy over the years (source: v3.1.0 release notes):

Version	Production Dep Count	Production Size
v3.1.0	×142	21.4 MB
v3.0.0	×187	27.4 MB
v2.0.1	×215	36.4 MB
v1.0.2	×356	73.3 MB

Some folks recommend disabling scripts when installing (via npm config set ignore-scripts true or via stock use of pnpm). This might be marginally useful in some cases but in my opinion is just a short term solution in response to common attack patterns that we’ve already seen. Importing (or requiring) a compromised or malicious package can execute arbitrary commands without using a preinstall or postinstall script just fine. If you really need to lock down your environment, you might consider running a Virtual Machine, Dev Container, and/or using Node.js’ Permissions model or stock Deno.

Stay safe out there, y’all!

Additional Reading

How to Hallucinate using Web Components

2025-11-21T06:00:00Z

Say, you want the smooth convenience of consuming content that feels like it’s generated in real time without having to deal with the tradeoffs of a Large Language Model née Artificial Intelligence.

Why not use animation? It’s the perfect metaphor for a Hollywood-esque veneer of complexity without substance, in no way similar to how an entire industry is currently being oversold and at no risk of imminent collapse.

This approach animates each blog post’s content (already generated by a human, manually) progressively to emulate existing chatbox user experience patterns for hallucinating text. You can try it out right now by hitting the Hallucinate toggle below:

How does it work?

This makes use of the <squirm-inal> Web Component, originally for Netlify’s Your Year on Netlify microsite and using lessons learned from Queue Code (a way to live code without live coding).

// It works with any arbitrary HTML content
// including this syntax highlighted code block
"use AI"

To implement this yourself, just wrap any arbitrary content (say <main>) in a newly created <squirm-inal autoplay speed="0.6"> element and you’re off to the races.

<script
	src="https://unpkg.com/@zachleat/squirminal@3.0.1/squirminal.js"
	integrity="sha384-m+pplzdzdfZuwjyxmM9pOkp/ALfMMjZll/b2g2mR6mhurvj1ZZAe8xXNj7BSp4XM"
	crossorigin="anonymous"></script>
<script type="module">
let main = document.querySelector("main");
let squirm = document.createElement("squirm-inal");
squirm.setAttribute("speed", "0.6");
squirm.setAttribute("autoplay", "");
squirm.append(...main.children);
main.append(squirm);
</script>

You could swap the <script src> above to use import() instead but that would remove the option for subresource integrity (always important for CDN use).

That’s it!

How we use GitHub Issues (on 11ty) and how that’s Changing

2025-11-03T06:00:00Z

Copy and Paste? …in this Economy?

2025-10-28T05:00:00Z

Astute visitors to the Eleventy Documentation will notice something new on the code blocks on the site.

A wild copy-to-clipboard component has appeared:

This feature been a long time coming and is our first use of Web Awesome on the docs (via the <wa-copy-button> custom element). Take special note of the unparalleled synergy of the Font Awesome icon used by the Web Awesome component used on the Eleventy docs.

Progressive Enhancement behavior: this is a JavaScript-only feature and has no before/without JavaScript experience. You might call this a JavaScript Web Component.
Performance-focused:
- This is using a build-time component bundle (read more about Bundling below)
- The JavaScript code for the component only loads when an instance is visible (via <is-land>)

Usage

Direct from CDN

There are a few ways to use the Copy Button component stock, with the easiest being to load the script directly from the CDN, like so (via jsdelivr):

<script type="module" src="https://cdn.jsdelivr.net/npm/@awesome.me/webawesome@3.0.0/dist-cdn/components/copy-button/copy-button.js"></script>

Or via unpkg:

<script type="module" src="https://unpkg.com/@awesome.me/webawesome@3.0.0/dist-cdn/components/copy-button/copy-button.js"></script>

Bundling

For this implementation we used esbuild to create a focused bundle for the single Web Awesome component (though this esbuild code would work for any JavaScript file).

We went with this method for improved runtime performance and to reduce the number of third-party dependencies on the web site (with a nod to André Jaenisch). You can do the same with the following bit of Eleventy configuration (e.g. in a eleventy.config.js file):

// eleventy.config.js
// don’t forget to `npm install esbuild -D`
import esbuild from "esbuild";
import { fileURLToPath } from "node:url";

async function esbuildToFile(entryPoints, outfile, options = {}) {
	return esbuild.build(Object.assign({
		entryPoints,
		platform: "browser",
		format: "esm",
		bundle: true,
		minify: true,
		banner: {
			js: `/* via ${entryPoints} */`,
		},
		outfile,
	}, options));
}

async function bundleModuleToFile(modulePath, outfile) {
	let sourcefile = fileURLToPath(import.meta.resolve(modulePath));
	return esbuildToFile([ sourcefile ], outfile);
}

export default async function(eleventyConfig) {
	let outfile = path.join(eleventyConfig.directories.output, "js/copy-button.js");

	// This will run once per build/serve/watch
	// (not with subsequent builds, save for config file changes)
	await bundleModuleToFile("@awesome.me/webawesome/dist/components/copy-button/copy-button.js", outfile);
}

Markdown Code Block Wrappers

This task also served as the impetus for fixes related to wrapper elements around code blocks in Markdown, documented in a previous blog post on this very web site.

Permanent Facepile Credit to Individuals Supporting Eleventy

2025-10-22T05:00:00Z

Every single page of the 11ty.dev Docs has a facepile in the footer, populated (automatically) by our Open Collective supporters list. Historically, to be a part of this facepile you needed to meet the following criteria:

Have an active recurring (monthly/yearly) Open Collective contribution (of any amount).
Have a non-default avatar or a web site added to your Open Collective profile that we can pull a favicon from.

Gold and silver tiers are shuffled randomly at build time but the Supporter tier is sorted by cumulative donation amount (descending).

Moving forward, the Gold and Silver tiers will still require active contributions but we’re relaxing the Supporter tier to be more inclusive of emeritus/former supporters:

Individuals contributing no longer need to be active and will be shown if cumulative contributions are greater than USD $55. This change means that one-time/non-recurring contributors will now be shown (if the amount meets stated minimums).
- Organization accounts will still need to have an active contribution to be shown. (Individual versus organization refers to the type of Open Collective account making the contribution)
If you have the default avatar (and no web site in your Open Collective profile) we will now show your entry in the facepile but the minimum cumulative total is USD $200 to use the default avatar. Too many folks don’t have an avatar or web site 😅 which makes the facepile look… well, not great. If you update your profile we will pick up your changes! The build runs (at minimum) daily.
Notably, it’s unchanged that there are no minimums for active recurring monthly/yearly contributions (for both individuals and organizations).

I hope this relaxation gives proper permanent credit to individuals that have contributed monetarily to the project, while filtering out the spam/bot accounts that have contributed a few dollars and subsequently immediately cancelled (hoping to be listed on the web site).

While I have y’all here I might also mention that your avatar links directly to the web site listed in your Open Collective profile. While these links do use rel="sponsored", it can help your search engine rank so it helps to configure your Open Collective profile appropriately!

Appreciate y’all!