Spotlighting the shared packages this site quietly depends on

The GitHub widget on this site’s homepage has always shown pinned-repo cards pulled live from a stats API: trello-extractor, programming-problems, homelab-tools, astro-blog. That’s fine for personal projects, but it buries the more interesting story. Three of the packages I’ve built - astro-blog, astro-affiliate, astro-opt-in-analytics - aren’t side projects. They’re infrastructure. Every site in the vdaluz.com family runs on them in production right now.

Why a new subsection instead of just adding to the pinned list

The auto-generated cards pull whatever stats a third-party service returns: stars, language, a one-line GitHub description. That’s the wrong pitch for these three. Nobody cares that astro-affiliate has zero stars. What matters is that it’s the affiliate-link resolver every post on this site and vdaluz.com runs through. So I added a “Shared packages” subsection above the existing block, hand-written pitches sourced straight from each package’s own package.json description rather than paraphrased from memory, and left the auto-generated block alone below it.

export const sharedPackages: SharedPackage[] = [
  {
    name: 'astro-blog',
    pitch: 'Shared Astro blog components, related-posts scoring, schema factory...',
    href: 'https://github.com/vdaluz/astro-blog',
  },
  // ...
];

The gotcha: verifying UI changes for a check that doesn’t exist

This repo’s own conventions call for running npm run a11y on any UI change. I went to run it and found there’s no such script here - it exists on vdaluz.com, not on this site. I’d assumed the tooling was shared across the family the same way the packages are. It isn’t.

Rather than skip the check, I ran npx @axe-core/cli directly against a local astro preview server:

npx @axe-core/cli http://localhost:4322/ --tags wcag2a,wcag2aa
0 violations found!

That’s a fine one-off, but it’s not something the next person (or the next me) will remember to run. I filed a follow-up to actually add the script here instead of leaving it as a manual workaround that only exists in this session’s shell history.

Results

astro check, prettier --check, and astro build all pass clean. Screenshotted the rendered preview to confirm the new subsection sits where it should, styled consistently with the rest of the page’s .glass card treatment. Zero a11y violations on the homepage.

Lesson

“This repo follows the same conventions as its siblings” is an assumption worth checking, not trusting. The four Astro sites in this family share a stack, but not every piece of tooling made it to every repo - and the gap doesn’t show up until you actually try to run the check.