Eleventy Excellent
Delete what the integration retired
Everything dead has been left in the tree until now, which makes this one pass you can verify in a single check. Confirm zero inbound references for each file before it goes.
| what | files | dead since |
|---|---|---|
| head partials | 7 | the head swap |
| schema templates | 2 | the schema data file |
| asset build events | 2 | the assets pipeline |
| committed OG images | 14 | the move to dist/ |
Plus _config/filters/striptags.js, orphaned by the head swap along with the partial that used it. With the partials gone, src/_includes/head/ is empty and the directory goes too.
The fourteen JPEGs are the deletion worth pausing on. They are build output living in source control, regenerated on every build and committed anyway, and nothing marks them as a problem until generation moves to dist/. If your starter commits its share cards, you have the same fourteen files.
Drop the dependencies that lost their importer
Four packages come out, and you land on 42 rather than 41, because npm-run-all went in earlier.
npm uninstall esbuild postcss-cli fast-glob sanitize-htmlThe first three had one importer each, all of it in code you deleted in the assets step. sanitize-html is the odd one out: nothing in the starter imports it, in any version. You find things like that by making yourself justify every remaining dependency once.
What a green build will not tell you
Eleventy exits zero on a site that is quietly broken, and most of what goes wrong in this integration is silent rather than fatal.
Walk the site on the dev server first, looking for what a person would notice. Then build it for production with the origin you actually deploy to, because --serve and npm run build take different branches through the asset pipeline.
BASELINE_URL=https://www.example.com/ npm run buildIt will pass. Go and look at dist/ rather than at the exit code, and count things rather than checking they exist.
View the six checks
- The file count.
[11ty] Wrote N filesagainst the number you had before you started. It is the cheapest check available and it catches an empty collection, which nothing else here will. - Tag counts, not tag presence. A uniform drop from ten OG tags to nine is invisible to a presence check. Look at a post rather than the home page: a per-page
og:imageresolves through a different path than the site default, and a missing one degrades to absent rather than to the fallback. - Attributes, not elements. A tag census cannot see a lost attribute. Grep the output for each attribute you believe you configured and count against the page count:
grep -rl 'use-credentials' dist --include='*.html' | wc -l. - Payload, not markup. A
<link>proves the tag, not the stylesheet behind it. Grep the built output for a rule you know is in your CSS. - Template syntax in built assets. No
{{or{%anywhere underdist/assets/, and no@import-globsurviving into the built CSS. Neither esbuild nor PostCSS renders templates, and neither complains. - Machine outputs that are not web pages.
head -c 40onrobots.txt, the feeds and the manifest. Eleventy has no notion that a file ending.txtshould not have a layout applied to it.
They are all counts rather than looks, because a presence check will pass on a page that is missing exactly the thing you changed.
Not covered here
Markdown plugins. Baseline composes with an existing markdown-it stack rather than replacing it, and this starter's is load-bearing. Leave yours alone.
The starter's own prose. docs/ still describes mechanisms this integration removes. That is the starter author's copy rather than the integrator's.
Multilingual sites. The starter is single-language and so is this guide. The multilang module is a different conversation.