# eleventy-excellent: an Eleventy starter built on CUBE and Every Layout

> Eleventy Excellent is a starter for the Eleventy static site generator that arrives with a design token system, a flexbox layout model, accessible dark and light modes and a large set of build plugins already wired up. It fits a team that wants a complete, opinionated front end rather than a blank Eleventy project, and it is a starting point you are expected to edit rather than depend on.

**madrilene/eleventy-excellent** — Eleventy starter with CUBE CSS, Every Layout and global design tokens. A workflow for modern & resilient websites, based on the CUBE CSS boilerplate.

- Repository: https://github.com/madrilene/eleventy-excellent
- Website: https://eleventy-excellent.netlify.app/
- Stars: 617 · Forks: 118
- Language: Nunjucks
- License: NOASSERTION
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/madrilene-eleventy-excellent

## A starter that arrives as a finished front end

Eleventy Excellent is an easy to use Eleventy starter, based on the workflow suggested by Andy Bell's buildexcellentwebsit.es. The README is unusually open about its intent, since there is a Built with Eleventy Excellent page listing sites built on it and a request to add yours by pull request.

The starter is based on the CUBE CSS boilerplate, created by Andy Bell and available under the MIT License. The topics list names Every Layout and CUBE as the underlying ideas, and the credits section makes the lineage explicit: Andy Bell for the browser's mentor idea and the Cube and buildexcellentwebsit.es resources, Heydon Pickering for Every Layout and inclusive-components, Zach Leatherman for Eleventy itself, Stephanie Eckles for smolcss.dev and moderncss.dev, and Manuel Matuzović for the accessible navigation that the default menu was inspired by.

What makes this more than a template is the size of the feature list. Accessible site navigation editable in src/_data/navigation.js, image optimisation with Eleventy-img, YouTube embeds with lite-youtube, resource fetching with eleventy-fetch, syntax highlighting with eleventy-plugin-syntaxhighlight, advanced markdown handling, 301 redirects for Netlify, automatically generated Open Graph images for blog posts, an XML sitemap, tags in blog posts, accessible blog pagination, and a style guide.

The audience is a developer who wants a working site today. The licence is one GitHub cannot classify, with a LICENSE.MD at the repository root, and the last push was on 2026-10-18 with the repository not archived. Releases are regular: v4.7.0 in July 2026, v4.8.0 in September and v4.9.0 on 2026-10-16.

## The Eleventy plugins that come pre-wired

The dependency list is where the starter's scope becomes clear, and it is worth reading as a shopping list of solved problems.

The core is @11ty/eleventy at 3.1.7, so this is Eleventy 3. The plugins cover the four things every content site needs and that most people get wrong. @11ty/eleventy-fetch at 5.1.3 handles resource fetching, pulling in remote content at build time. @11ty/eleventy-img at 7.0.0 does image optimisation. @11ty/eleventy-plugin-rss at 3.1.0 produces the feed, and the README notes that the feed now supports more than one. @11ty/eleventy-plugin-syntaxhighlight at 5.0.2 does code highlighting. @11ty/eleventy-plugin-webc is pinned to 0.12.0-beta.7, a beta version pinned exactly, which tells you the author is tracking a moving dependency deliberately.

Then there are the small ones that show the level of care. @11ty/is-land at 5.0.1 is the island architecture helper. canvas-confetti at 1.9.4 and lite-youtube-embed at 0.3.4 are two small, focused dependencies doing one thing each, which is the right shape for a starter because you can delete them when you do not need them.

Tailwind CSS is present at 3.4.17, but the README flags it as Tailwind CSS but not how you might expect, and points at a blog post explaining it. The tailwind.config.js at the repository root is the place to check what it actually does, and the answer matters, because a starter that installs Tailwind by default when you wanted plain CSS is an annoyance, and one that installs it in a non-obvious way is a learning opportunity.

The other clue to the build approach is in the scripts. Bundling via esbuild is listed as a feature, and the clean script removes dist plus src/_includes/css and src/_includes/scripts, which tells you the CSS and JavaScript are compiled into those include directories rather than served raw.

## The npm scripts describe the whole workflow, including accessibility

The scripts section of package.json is the most useful part of the repository for an adopter, because it documents the intended workflow rather than the feature list.

Development is two commands. npm install pulls the dependencies, and npm start runs the watch mode, which the README describes as starting watch tasks to compile when changes are detected.

```bash
npm install
npm start
```

A production build is npm run build, which the README says minifies JS, CSS and HTML.

```bash
npm run build
``` Underneath, the build script chains a clean step and a build:11ty step, and build:11ty runs Eleventy with ELEVENTY_ENV=production, while dev:11ty runs the same binary with ELEVENTY_ENV=development and the serve flag. That environment variable is the switch the whole project uses to behave differently between development and production.

The interesting scripts are the setup ones. colors runs a script named create-colors.js, favicons runs generate-favicons.js, screenshots runs generate-screenshots.js, and clean:og removes the generated Open Graph image directory. The separation of a clean:og target from the main clean target is a small sign of care: regenerating the social images is expensive, so it is separated from wiping the build.

Then there is the accessibility suite. pa11y:build does a clean and an Eleventy build with ELEVENTY_ENV=test, pa11y:serve serves that build, pa11y:test runs pa11y-ci with a config file, and test:a11y chains all three with sleeps in between to let the server come up. So the starter does not merely claim to be accessible, it ships a command that checks it, which is a much stronger position than a bullet point in a feature list.

There is also a transpiled tailwind.config.js and an eleventy.config.js at the root, plus netlify.toml and vercel.json, so both Netlify and Vercel are deployment targets, and the site itself is hosted on Netlify at eleventy-excellent.netlify.app.

## Design tokens, dark mode and the accessibility commitments

The design side of the starter is what distinguishes it from a plain Eleventy template, and it comes from two named systems.

The first is CUBE, the CSS boilerplate from Andy Bell, which brings a set of global design tokens rather than raw values scattered through templates. The second is Every Layout by Heydon Pickering, which provides the flexbox-like layout primitives for the container and stack patterns. The result is a site where spacing and colour come from a token set, and where the layout approach is a documented system rather than ad hoc rules.

The accessibility commitments are concrete rather than aspirational. The README lists accessible site navigation, an accessible blog pagination, and accessible dark and light mode based on user preference with a custom toggle. The dark mode work is credited to Sara Soueidan, whose recommendations for accessible theme switching and pagination in the Practical Accessibility course the author says they looked at closely. The navigation itself is credited to Manuel Matuzović, with the default menu up to version 2 being heavily inspired by an article he wrote on web.dev.

Two more features fit this pattern. There is an opt-in /llms.txt site summary, plus configurable crawl rules in robots.txt, which is a small nod to machine-readable site summaries. And there is carbon.txt, described as a way to show that the site's digital infrastructure runs on green electricity, which is a decorative gesture rather than a measurement.

The style guide is listed as a feature, with a trademark symbol, and the README explains that the style guide was inspired by a talk on the Eleventy Meetup, with a blog post by Steven Woodson walking through adding it to an existing site.

Also worth noting: the OG image implementation is based on an article by Bernard Nijenhuis on automatically generating Open Graph images in Eleventy, and the 301 redirect solution comes from an article by Aleksandr Hovhannisyan.

## The README keeps a list of dependency chains it has chosen not to fix

There is a section in the README called Vulnerability Notes, updated 2026-08-28, and it is short enough to quote in full because the detail is the point.

There is one entry, for the extract-zip package. The chain is given as pa11y-ci pulling puppeteer, which pulls @puppeteer/browsers, which pulls extract-zip. The note says it is ignored until pa11y or Puppeteer drops extract-zip.

This is worth dwelling on for a second, because it is a good pattern and a bad one at the same time. The good part is that a starter which installs a browser automation stack for accessibility testing has a known transitive dependency issue, and the author has written it down with the date it was last reviewed. The bad part is that the resolution is to wait for an upstream project rather than pin, patch or drop the dependency, and the starter's own accessibility test command is what pulls pa11y in.

So the accessibility tooling that makes this starter worth using is also the source of the vulnerability note. That is a genuine tension in the project, and it is much better that it is documented in the README with a date than that it is not mentioned.

For an adopter, the practical reading is that you should check the current state of that chain before you rely on the test:a11y target in CI, and that the note's resolution date tells you how fresh the review is. The last push to the repository was on 2026-10-18, and the note was last updated on 2026-08-28, so the two dates are about seven weeks apart, which is reasonably recent.

## Where eleventy-excellent is the wrong tool

The first wrong-tool case is a project with an existing design system. This starter is opinionated about tokens, colour and layout, and its value comes from that opinion being applied consistently. Bolting it onto a codebase with its own CSS architecture means fighting the starter, and the token layer is exactly the part you would want to replace.

The second is a team that wants a minimal build. The dependency list includes a beta-pinned plugin, a canvas library, a YouTube embed helper and an island architecture helper, none of which most sites need. The clean script exists to remove generated CSS and scripts, but the dependencies themselves stay in package.json unless you delete them. A twelve-dependency starter for a site with three pages is a poor trade.

The third is a React-shop that has standardised on a component framework. The starter is Nunjucks templates with server-rendered HTML and a small amount of progressive enhancement, and the is-land helper is for islands rather than for a component tree. That is a sound approach for a content site and a wrong one for a product with a stateful UI.

The fourth is a project that cannot maintain a forked starter. Eleventy Excellent is a starting point you are expected to edit and then own. When the upstream fixes a bug in the accessibility suite or updates a plugin, you are not getting that update unless you merge it, and you are merging it into a codebase you have by then changed considerably. The version numbers here, 4.7, 4.8 and 4.9 within one quarter, show how fast it moves, which is good for a starter and expensive for a fork.

The fifth is a static site that needs a server. There is no runtime component here at all, which is the point of Eleventy, and a site with per-user state has to be built on something else.

## Conclusion

eleventy-excellent fits a developer starting a content site who wants accessibility, a token-based CSS system and a working set of Eleventy plugins on day one rather than assembling them over a week. It is the wrong choice for a project with an existing design system, for a team that wants a minimal build, and for anyone who will not maintain the starter's own dependencies. Before adopting it, run the accessibility test target, since pa11y is part of the toolchain and will surface problems early, and read the vulnerability notes, since the README keeps an explicit list of dependency chains it has chosen not to fix.

## FAQ

### What is eleventy-excellent?

It is an easy to use Eleventy starter based on the workflow suggested by Andy Bell's buildexcellentwebsit.es, built on the CUBE CSS boilerplate and Every Layout, with global design tokens and a wide set of build plugins already wired up.

### How do I run the eleventy-excellent site locally?

Run npm install to get the dependencies, then npm start, which the README describes as starting watch tasks to compile when changes are detected, and npm run build creates a minified production build.

### Does eleventy-excellent include accessibility testing?

Yes, the scripts include pa11y:build, pa11y:serve, pa11y:test and a combined test:a11y target that runs pa11y-ci against the built site.

### What does the eleventy-excellent vulnerability note cover?

It covers the extract-zip package, reached through the chain pa11y-ci to puppeteer to @puppeteer/browsers to extract-zip, and it says this is ignored until pa11y or Puppeteer drops extract-zip, with the note last updated on 2026-08-28.

## Sources

- [Issues](https://github.com/madrilene/eleventy-excellent/issues)
- [madrilene/eleventy-excellent on GitHub](https://github.com/madrilene/eleventy-excellent)
- [Project website](https://eleventy-excellent.netlify.app/)
- [README](https://github.com/madrilene/eleventy-excellent/blob/main/README.md)
- [Releases](https://github.com/madrilene/eleventy-excellent/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/madrilene-eleventy-excellent