plugin-kit 0.4.1 — publish the icon field, without which no plugin can name its mark #186

Merged

enricobuehler merged 1 commits from worktree-launcher-icon-kit-release into main 2026-08-12 22:30:16 +00:00

Conversation 0 Commits 1 Files Changed 1

+1 -1

enricobuehler commented 2026-08-12 22:29:52 +00:00

Owner

Copy Link

Copy Source

Launcher icons have been inert since they landed, in every client, and this is the first of three changes that fix it.

What is actually broken

f62a48d4 shipped the launcher-icon token end to end: the host-side shape guard, the seven masters under assets/launcher-icons/, six client renderers, the SDK and the OpenAPI. The web console's half is complete and correct — web/src/components/launcher-icon.tsx holds the generated registry and GameCard.tsx:70 draws a mark whenever a launcher tile has no cover art.

What it never gets is a token to draw. Nothing in the host ever sets icon: every built-in provider constructs icon: None, custom.rs passes input straight through, and the host creates no role: "launcher" entries at all. Launcher tiles come exclusively from library plugins, so a plugin's launcherEntries() is the one and only producer of this field.

And no plugin can produce it, because of this bug:

• ProviderEntry.icon was added to the kit in f62a48d4 without a version bump.
• The kit had cut 0.4.0 the day before, in 6b7997ca.
• So the registry's 0.4.0 is the tarball without the field — and it is the newest thing any plugin can resolve.

A plugin that emits icon on a launcher entry therefore fails tsc --noEmit:

src/plugin.ts(178,4): error TS2353: Object literal may only specify known properties,
and 'icon' does not exist in type '{ readonly title: string; ... }'.

which is a CI gate in every plugin repo. That is why the three plugins meant to carry the token never shipped it — the edits could not be committed against a kit that had no field to fill.

This change

The version, and nothing else. The only plugin-kit change since 0.4.0 was published is f62a48d4 itself, so 0.4.1 is exactly that commit's kit surface: one optional string on an existing struct. Additive, and inert for a plugin that never sets it.

plugin-kit/bun.lock does not record the package's own version, so it needs no update.

Release

Merging this does not publish. plugin-kit-publish.yml fires on a plugin-kit-v* tag and guards that the tag equals plugin-kit/package.json, so plugin-kit-v0.4.1 gets pushed after this merges.

What follows

1. this PR — publish the kit field.
2. @punktfunk/plugin-{steam,lutris,heroic} — depend on ^0.4.1, emit the token, release 0.1.1.
3. Update the hosts and drop the temporary hand-patch currently making 192.168.1.41 work.

Verified

origin/main at 907080f9. Confirmed against the published tarball that 0.4.0's dist/wire.d.ts has no icon on ProviderEntry (its only icon is the unrelated lucide nav name in ui-server.d.ts), and reproduced the TS2353 failure in punktfunk-plugin-steam against both 0.3.3 and 0.4.0.

Launcher icons have been inert since they landed, in **every** client, and this is the first of three changes that fix it. ## What is actually broken `f62a48d4` shipped the launcher-icon token end to end: the host-side shape guard, the seven masters under `assets/launcher-icons/`, six client renderers, the SDK and the OpenAPI. The web console's half is complete and correct — `web/src/components/launcher-icon.tsx` holds the generated registry and `GameCard.tsx:70` draws a mark whenever a launcher tile has no cover art. What it never gets is a token to draw. **Nothing in the host ever sets `icon`**: every built-in provider constructs `icon: None`, `custom.rs` passes input straight through, and the host creates no `role: "launcher"` entries at all. Launcher tiles come exclusively from library plugins, so a plugin's `launcherEntries()` is the one and only producer of this field. And no plugin can produce it, because of this bug: - `ProviderEntry.icon` was added to the kit in `f62a48d4` **without a version bump**. - The kit had cut `0.4.0` the day before, in `6b7997ca`. - So the registry's `0.4.0` is the tarball *without* the field — and it is the newest thing any plugin can resolve. A plugin that emits `icon` on a launcher entry therefore fails `tsc --noEmit`: ``` src/plugin.ts(178,4): error TS2353: Object literal may only specify known properties, and 'icon' does not exist in type '{ readonly title: string; ... }'. ``` which is a CI gate in every plugin repo. That is why the three plugins meant to carry the token never shipped it — the edits could not be committed against a kit that had no field to fill. ## This change The version, and nothing else. The only plugin-kit change since `0.4.0` was published is `f62a48d4` itself, so `0.4.1` is exactly that commit's kit surface: one optional string on an existing struct. Additive, and inert for a plugin that never sets it. `plugin-kit/bun.lock` does not record the package's own version, so it needs no update. ## Release Merging this does **not** publish. `plugin-kit-publish.yml` fires on a `plugin-kit-v*` tag and guards that the tag equals `plugin-kit/package.json`, so `plugin-kit-v0.4.1` gets pushed after this merges. ## What follows 1. **this PR** — publish the kit field. 2. `@punktfunk/plugin-{steam,lutris,heroic}` — depend on `^0.4.1`, emit the token, release `0.1.1`. 3. Update the hosts and drop the temporary hand-patch currently making `192.168.1.41` work. ## Verified `origin/main` at `907080f9`. Confirmed against the published tarball that `0.4.0`'s `dist/wire.d.ts` has no `icon` on `ProviderEntry` (its only `icon` is the unrelated lucide nav name in `ui-server.d.ts`), and reproduced the `TS2353` failure in `punktfunk-plugin-steam` against both `0.3.3` and `0.4.0`.

enricobuehler added 1 commit 2026-08-12 22:29:54 +00:00

chore(plugin-kit): 0.4.1 — publish the icon field, without which no plugin can name its mark ... d6dbb391d6

`ProviderEntry.icon` landed in f62a48d4 along with the token's whole
supporting cast: the host-side shape guard, the seven masters, six client
renderers, the SDK and the OpenAPI. What it did not get was a version
bump, and the kit had cut 0.4.0 the day before.

So the registry's 0.4.0 is the tarball WITHOUT the field, and it is the
newest thing any plugin can resolve. A plugin that emits `icon` on a
launcher entry therefore fails `tsc --noEmit` — "Object literal may only
specify known properties, and 'icon' does not exist" — which is a CI gate
in every plugin repo. That is why the three plugins that were supposed to
carry the token never shipped it: the edits could not be committed
against a kit that had no field to fill.

Nothing but the version moves here. The only plugin-kit change since
0.4.0 was published is f62a48d4 itself, so 0.4.1 is exactly that commit's
kit surface — one optional string on an existing struct, additive, and
inert for a plugin that never sets it.

enricobuehler merged commit f06b84be63 into main 2026-08-12 22:30:16 +00:00

enricobuehler deleted branch worktree-launcher-icon-kit-release 2026-08-12 22:30:20 +00:00

Sign in to join this conversation.

Reviewers

No Reviewers

Labels

No items

No labels

Milestone

No items

No Milestone

Projects

Clear projects

No projects

Assignees

Clear assignees

FernandoMX enricobuehler (Enrico Bühler) kszlim nannku neoney sassycrown

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: unom/punktfunk#186