One line, but it's the thing standing between two merged PRs and a working plugin.
Why now
punktfunk-plugin-rom-manager merged its consuming change (#1 there) while still pinning @punktfunk/plugin-kit@^0.2.0. Its CI runs bun install --frozen-lockfile then typecheck on every push to main, and the registry's newest kit has none of the exports that change uses — so rom-manager's main is red right now, with three errors naming exactly serveUi({launch}), PluginLaunchTarget and SyncError.message.
The order matters and only works one way: the kit has to be on the registry before rom-manager's lockfile can resolve it. So this lands first, gets tagged, and then rom-manager's pin moves off ^0.2.0.
Why 0.4.0
New API surface from #129, not a fix — serveUi({launch}), PluginLaunchTarget, makeLaunchHandler, plus SyncError finally rendering its cause. Registry latest is 0.3.3. Additive, so every other plugin pinning ^0.3.x or ^0.2.0 is unaffected; only rom-manager needs the pin change.
Verified
Ran the publish workflow's own gates locally, in order and including its file:-dependency repair step: SDK build → bun install --frozen-lockfile → bun run check → bun run typecheck → bun test (79 pass) → bun run build. require('./package.json').version reads 0.4.0, which is what the workflow's tag-match guard asserts against.
After merge
Tag plugin-kit-v0.4.0 to trigger plugin-kit-publish.yml. I have not tagged anything — publishing is a one-way door onto a shared registry, so that's a call for a human to make.
One line, but it's the thing standing between two merged PRs and a working plugin.
## Why now
`punktfunk-plugin-rom-manager` merged its consuming change (#1 there) while still pinning `@punktfunk/plugin-kit@^0.2.0`. Its CI runs `bun install --frozen-lockfile` then typecheck on every push to `main`, and the registry's newest kit has none of the exports that change uses — so **rom-manager's main is red right now**, with three errors naming exactly `serveUi({launch})`, `PluginLaunchTarget` and `SyncError.message`.
The order matters and only works one way: the kit has to be **on the registry** before rom-manager's lockfile can resolve it. So this lands first, gets tagged, and then rom-manager's pin moves off `^0.2.0`.
## Why 0.4.0
New API surface from #129, not a fix — `serveUi({launch})`, `PluginLaunchTarget`, `makeLaunchHandler`, plus `SyncError` finally rendering its cause. Registry `latest` is 0.3.3. Additive, so every other plugin pinning `^0.3.x` or `^0.2.0` is unaffected; only rom-manager needs the pin change.
## Verified
Ran the publish workflow's own gates locally, in order and including its `file:`-dependency repair step: SDK build → `bun install --frozen-lockfile` → `bun run check` → `bun run typecheck` → `bun test` (79 pass) → `bun run build`. `require('./package.json').version` reads `0.4.0`, which is what the workflow's tag-match guard asserts against.
## After merge
Tag `plugin-kit-v0.4.0` to trigger `plugin-kit-publish.yml`. I have not tagged anything — publishing is a one-way door onto a shared registry, so that's a call for a human to make.
`serveUi({launch})`, `PluginLaunchTarget` and `makeLaunchHandler` (#129) are new API, so this is a
minor bump rather than a patch. It also carries `SyncError.message`, without which a host refusal
reaches a plugin's own UI as the bare tag `SyncError` and nothing else.
Unblocks rom-manager, whose main is currently RED: it merged the consuming change while still
pinning `^0.2.0`, so `bun install --frozen-lockfile` there resolves a kit without these exports and
the typecheck fails on all three. Publishing this and then bumping that pin is the fix — in that
order, because the lockfile cannot resolve 0.4.0 until it exists on the registry.
Tag `plugin-kit-v0.4.0` to publish; the workflow asserts the tag matches this version.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
One line, but it's the thing standing between two merged PRs and a working plugin.
Why now
punktfunk-plugin-rom-managermerged its consuming change (#1 there) while still pinning@punktfunk/plugin-kit@^0.2.0. Its CI runsbun install --frozen-lockfilethen typecheck on every push tomain, and the registry's newest kit has none of the exports that change uses — so rom-manager's main is red right now, with three errors naming exactlyserveUi({launch}),PluginLaunchTargetandSyncError.message.The order matters and only works one way: the kit has to be on the registry before rom-manager's lockfile can resolve it. So this lands first, gets tagged, and then rom-manager's pin moves off
^0.2.0.Why 0.4.0
New API surface from #129, not a fix —
serveUi({launch}),PluginLaunchTarget,makeLaunchHandler, plusSyncErrorfinally rendering its cause. Registrylatestis 0.3.3. Additive, so every other plugin pinning^0.3.xor^0.2.0is unaffected; only rom-manager needs the pin change.Verified
Ran the publish workflow's own gates locally, in order and including its
file:-dependency repair step: SDK build →bun install --frozen-lockfile→bun run check→bun run typecheck→bun test(79 pass) →bun run build.require('./package.json').versionreads0.4.0, which is what the workflow's tag-match guard asserts against.After merge
Tag
plugin-kit-v0.4.0to triggerplugin-kit-publish.yml. I have not tagged anything — publishing is a one-way door onto a shared registry, so that's a call for a human to make.`serveUi({launch})`, `PluginLaunchTarget` and `makeLaunchHandler` (#129) are new API, so this is a minor bump rather than a patch. It also carries `SyncError.message`, without which a host refusal reaches a plugin's own UI as the bare tag `SyncError` and nothing else. Unblocks rom-manager, whose main is currently RED: it merged the consuming change while still pinning `^0.2.0`, so `bun install --frozen-lockfile` there resolves a kit without these exports and the typecheck fails on all three. Publishing this and then bumping that pin is the fix — in that order, because the lockfile cannot resolve 0.4.0 until it exists on the registry. Tag `plugin-kit-v0.4.0` to publish; the workflow asserts the tag matches this version.