From d6dbb391d6372395a34d37b6d2c05bf86598dd94 Mon Sep 17 00:00:00 2001 From: enricobuehler Date: Thu, 13 Aug 2026 00:29:26 +0200 Subject: [PATCH] =?UTF-8?q?chore(plugin-kit):=200.4.1=20=E2=80=94=20publis?= =?UTF-8?q?h=20the=20`icon`=20field,=20without=20which=20no=20plugin=20can?= =?UTF-8?q?=20name=20its=20mark?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit `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. --- plugin-kit/package.json | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugin-kit/package.json b/plugin-kit/package.json index e164405f..eb8fa5d3 100644 --- a/plugin-kit/package.json +++ b/plugin-kit/package.json @@ -1,6 +1,6 @@ { "name": "@punktfunk/plugin-kit", - "version": "0.4.0", + "version": "0.4.1", "description": "Effect-based framework for punktfunk plugins: lifecycle runtime, config/state, sync engine, UI serving, CLI scaffold, and browser helpers.", "type": "module", "license": "MIT OR Apache-2.0", -- 2.54.0