EmDash 0.1.1 — The First Patch Release

EmDash just shipped 0.1.1, the first patch release following 0.1.0. The upgrade is small in scope but introduces a few type-level changes worth documenting — especially if you're running a site against the generated collection types.

Upgrading

The upgrade itself is a one-liner:

npm install emdash@latest

After installing, start the dev server once to regenerate emdash-env.d.ts from your schema:

npx emdash dev

This runs pending migrations and rewrites the generated types for your collections. Skipping this step is what caused most of the type errors I saw on the first pass.

What needed adjusting

Running astro check after the upgrade surfaced 84 errors initially. Most of these cleared up automatically once the types were regenerated, leaving a handful of real breaking changes at the API surface.

1. MediaReference no longer exposes url in its type

The Base.astro layout referenced settings.favicon?.url and settings.logo?.url. At runtime, EmDash still attaches url to resolved media references — but the public MediaReference type now declares only mediaId and alt. A minimal local cast restores access without touching runtime behavior:

const favicon = settings.favicon as { url?: string; alt?: string } | undefined;
const logo = settings.logo as { url?: string; alt?: string } | undefined;

The template then uses favicon?.url and logo?.url as before.

2. excerpt is narrower across collections

The /api/search endpoint iterates entries from both posts and pages and previously read entry.data.excerpt directly. The regenerated types correctly reflect that Page has no excerpt field, so the direct access now fails type checking. A simple narrow resolves it:

const excerpt: string = ("excerpt" in entry.data ? entry.data.excerpt : "") ?? "";

This is a genuine improvement — the old code would have silently returned undefined for pages.

3. Housekeeping — Cloudflare Workers types

Unrelated to the EmDash upgrade, but worth mentioning: the image route used R2Bucket and import("cloudflare:workers") without the corresponding types installed. Adding @cloudflare/workers-types to the types array in tsconfig.json cleared those two errors as well.

Pre-deploy verification

Before shipping to production I ran:

• astro check — 0 errors, 0 warnings
• astro build — production build succeeded against the Cloudflare adapter
• Manual smoke test on the dev server — homepage rendered correctly, /api/search?q=the returned results with snippets and highlighting

Takeaway

0.1.1 is a small, focused release. If your site reads logo or favicon from site settings, or runs cross-collection queries that assume shared fields, expect to make the same two adjustments. Otherwise, it's a clean upgrade — and the stricter collection types are a welcome change.