The open source page that almost lied about its own version numbers

I added an Open Source page to this site: /open-source/, listing the four Astro packages I built for my own family of sites and ship publicly on GitHub. Simple idea. The interesting part was almost shipping wrong version numbers on a page whose entire pitch is “here’s what this site runs.”

The versions I checked, and the versions that mattered

The issue asked for a small content collection: one markdown file per package, frontmatter for name, tagline, version, status, highlights. Before writing any code I went and checked the latest release tag in each of the four repos. astro-blog v0.7.0, astro-affiliate v0.4.0, astro-og-cards v1.0.0, astro-opt-in-analytics v0.5.1. Wrote those in, built the page, ran the build.

Then I ran the accessibility check, which spins up a real build behind wrangler dev, and while it was running I happened to glance at this site’s own package.json. The pinned dependency versions did not match what I’d just written. astro-blog was on v0.6.2, astro-affiliate on v0.3.0, astro-opt-in-analytics on v0.5.0. Only astro-og-cards lined up, because it’s the newest addition and hasn’t had a release since this site adopted it.

So the page I’d just built would have told a visitor “this site runs v0.7.0 of astro-blog” while the site was in fact still running v0.6.2. Nobody would have noticed. It doesn’t break anything. It’s just a small, confident falsehood sitting on a page whose whole premise is that this stuff is real and I dogfood it - the same failure mode as the pinned-repos card that went stale.

Swapped every version field to the actual pinned tag from this repo’s own package.json, not the latest tag upstream. If I bump a dependency later, the page and the lockfile can drift again, but at least it starts out true.

The content collection I didn’t build

Before any of that, a smaller decision worth mentioning. The issue’s own suggestion was a real Astro content collection: markdown files with zod-validated frontmatter. I looked at what I was actually storing - a tagline, three highlight bullets, a version string - and realized there was no prose body anywhere in it.

A content collection earns its keep when there’s an actual markdown document to write. Here every field was short structured data, exactly the shape the site already had a working pattern for with its project cards. Adding a whole schema and loader for four entries with nothing but frontmatter was machinery built for a feature that wasn’t there. Went with the plain typed array instead, and the page shipped with a smaller diff for it.

Scope I deliberately left alone

I could have used the same pass to trim the homepage’s existing inline package list, which now duplicates part of what the new page shows. Held off. A planned follow-up (per-package detail pages) will give that homepage list somewhere real to link to; trimming it now would mean the homepage stops naming these packages at all for a while, with nothing yet built to replace that. Sequencing which piece of a multi-part feature goes out first matters as much as building any one piece correctly.

Lesson

None of this took long to fix. The part worth remembering is that “the packages this site runs on” is a claim, and a claim is only as good as the thing you checked it against. I checked the wrong thing first: upstream truth instead of local truth, when the sentence on the page was about local truth.