ARNO: 非官方插件安装后就算更新到最新版，magpie依然提示有更新. A third-party
plugin added as name@1.2.3 is pinned. The Plugins page still counts it
under "Update all (n)", its row says "vX out" and the Plugins dot is on.
Update all (and `magpie plugin update`) reinstalled the pinned version,
reported "Plugins updated", and the prompt stayed. The row's own Update
already installs the newest version and unpins the spec (name@latest).
Update now does the same for a pinned plugin when npm has a newer version
than the one installed: it installs that version through add, which keeps
the plugin's options and the provider picked for it. A pinned plugin that
is already at npm's newest keeps its pin. Git plugins, folders and plugins
npm didn't answer for behave as before. The plugin docs (en, zh, ja) now
say that updating a pinned plugin yourself unpins it.
Reproduced in a sandbox HOME with the real opencode-gemini-auth from npm
(magpie web on a spare port, China mirror switch on and off). Pinned at
1.4.15 with 2.0.1 out: before the fix, Update all and `magpie plugin
update` left it at 1.4.15 and /api/plugins/updates still listed it. After
the fix it is at 2.0.1 as opencode-gemini-auth@latest, the waiting list
is empty and Check for updates reports "current". The row's Update
(upgrade) path was checked too: unpinned opencode-gemini-auth, and scoped
@gitlab/opencode-gitlab-auth 1.3.1 -> 1.3.3 with the mirror on. Both
cleared the prompt before the fix as well.
TestUpdateAllUpdatesAPinnedPlugin (real bun, fake registry) fails without
the change: "Update all left opencode-someones-auth at 1.0.0, want 2.0.0".
gofmt -l, go vet (darwin, GOOS=linux, GOOS=windows) on internal/plugin,
and go test -tags nogui of internal/plugin, internal/gui and
internal/provider under a temp HOME with pinned caches all pass.
neiko on Discord installed a third-party plugin beside a plugin of their
own, added by its folder. Only the third-party one could be seen. Both
plugins' auth hooks name the same provider id. The host's auths() keeps
the last plugin in plugins.json for an id, as OpenCode does, so the
user's own plugin silently lost it:
- its row read "Signs in to nothing magpie can use";
- its provider was gone from the Add sheet;
- keepUnloaded could list the id a second time, from the
plugin-providers.json kept before.
A package-name clash and a display-name clash were tried as well. Both
plugins stay visible in those cases, because a folder plugin's name is
its path.
What changed:
- host.js:
- init gives each loaded plugin the ids it signs in to (provides) and,
for each id another plugin serves, that plugin's spec (servedBy).
- auths() honours plugins.json's new prefer map (id -> spec).
- Only the serving plugin's provider.models hook runs for the id.
- plugin:
- Clashes() turns provides and servedBy into {id, by, with} per spec.
- Prefer() records a pick and restarts the host.
- Remove drops the removed plugin's picks.
- Re-adding a plugin under a new spec carries its picks over.
- remove, off, options and prefer find a plugin by its exact spec
before its package name (indexOf), so acting on one plugin never
reaches another of the same package.
- keepUnloaded no longer re-adds a provider from before when another
plugin serves its id now.
- GUI:
- /api/plugins rows carry clashes, with the provider's listed name.
- POST /api/plugins/prefer {spec, provider}.
- The serving row says "{other} signs in to {name} too; this one
serves it".
- The other row says, in amber, "{name} is served by {other}, which
signs in to it too", with a "Use for {name}" button.
- New strings in zh, zh-TW, ja and de.
- CLI: `magpie plugin` prints the same lines, with the command that
fixes it, and `magpie plugin use <name> <provider>` makes the pick.
- Docs: docs/subsystems/provider-plugins.md, docs/reference.md and
site/public/docs/{,zh/,ja/}plugins.html.
What was run:
- Reproduced under a sandbox HOME with magpie web on 3562: a fake npm
plugin and a folder plugin, both on id "acme".
- Old binary: the local row had providers [] and /api/providers
listed acme twice.
- New binary: both rows carry the clash; prefer moves acme to the
folder plugin; remove clears the pick and leaves the other plugin
serving acme.
- New Go tests:
- TestTwoPluginsOneProvider, a real Bun host: Prefer, restart,
off/on and Remove.
- TestClashes, TestPluginNamedExactlyFirst and
TestKeepUnloadedLeavesAServedID.
- TestPluginsClashRows (gui) and TestPluginListSaysClash (CLI).
- Each fails when its piece is broken by hand: prefer ignored in
host.js, the keepUnloaded id check removed, name before exact spec,
Remove keeping picks, no provides, no clashes in the rows, no
prefer route.
- plugin-clash.test.cjs, in Chromium and WebKit, in en, zh, zh-TW, ja
and de, at 1100 and 560px: 22/22 pass. It times out on the old
plugins.js.
- gui-de, gui-ja, gui-zh-tw, i18n-keys and every plugin-*.test.cjs:
248 tests.
- 245 passed in the 4-wide run.
- plugin-moved-signin (webkit) failed once in that run, then passed
3/3 alone and 26/26 in a smaller 4-wide rerun.
- gofmt -l; go vet ./...; GOOS=linux and GOOS=windows go vet -tags
nogui ./...; go build ./...
- The full go test -tags nogui ./... under a temp HOME with the caches
pinned: 44 packages ok, none failed.
- After rebasing onto 05917100 (plugins.css conflict with a3a8e257's
chip rules, both kept): plugin, gui and the root plugin tests, vet on
darwin, linux and windows, and the 248 GUI tests above, all green
(248/248 this time).
Not tried: a real third-party plugin, neiko's own plugins, and Windows
beyond vet.
What: Update, Update all, the hourly auto-update and the move's install
ask npm for the plugin's newest version and have bun install that exact
version (installAt), then check it is the one installed. When bun won't,
the error says why, reason first for the status pill: "<pkg> 0.1.21 isn't
installed yet: Bun's minimumReleaseAge (in a .bunfig.toml) holds back
versions published less than 2 days ago, and magpie installs it once it
is older (bun's own words)". Another bun error (a registry of the user's
own without the version) is "<pkg> <v> isn't installed: <bun's error:
lines>". Specs stay as they were (name@latest); pinned and git plugins,
and npm not answering, install as their spec says, as before.
Why: the Factory card stayed at 0.1.18 with 0.1.21 out, through clicking
update and restarts. bun add pkg@latest resolves "latest" by bun's own
config: a minimumReleaseAge in the user's ~/.bunfig.toml or
$XDG_CONFIG_HOME/.bunfig.toml makes it install the newest version older
than that and exit 0. 172800s (2 days) gives exactly 0.1.18 (0.1.19-21
were published 10-08). So every update path succeeded with nothing
changed, and the page said "updated to v0.1.21". Asked for 0.1.21 itself,
bun fails with "blocked by minimum-release-age: 172800 seconds". The same
code serves every moved plugin (Cursor, Devin, Kiro, Qoder, ...), so all
of them had it. npm view: 0.1.21 is latest; npmmirror has it too.
Run:
- TestUpdateBunHoldsBackSaysWhy (new): real bun 1.4.2 against a fake
registry with 0.1.18 (3 days old) and 0.1.21 (1 hour), a bunfig with
minimumReleaseAge = 172800. On the old code it fails: "Update with
0.1.21 held back by Bun: <nil>, want bun's reason (installed 0.1.18)".
Breaking Update alone fails at "Update all: <nil>", breaking the hourly
update alone at "the hourly update: <nil>". Without the bunfig it
installs 0.1.21 and keeps the spec @latest.
- Real use: magpie web (nogui build) under a sandbox HOME, real npm, with
the bunfig: add factory-auth@0.1.18, spec @latest, POST
/api/plugins/upgrade and /update return the reason above, the card
stays 0.1.18; bunfig removed, upgrade installs 0.1.21.
- Ruled out on macOS and the Windows box: plain upgrade 0.1.18 -> 0.1.21
works there without a bunfig, host running or not.
- gofmt -l; go vet (darwin, GOOS=linux, GOOS=windows, -tags nogui) on
internal/plugin, internal/provider, internal/gui; go build (darwin),
GOOS=linux and GOOS=windows -tags nogui builds; go test -tags nogui ./...
under a temp HOME, all ok.
A repository tagged magpie-plugin whose npm copy (from that repository)
names no file to load (no main, no exports) was listed and installed from
npm without the entry check the GitHub route has; it then failed every
host start with "has no entry" and a stack. Now:
- the Unreviewed list checks npm's copy the same way: one that names no
file needs the index.js the repository's own route needs (askTagged);
- `magpie plugin add` / the Plugins page refuse a package that names no
file, has no index file and is neither pi's nor a middleware, take the
package just installed for it out again, and say it isn't an OpenCode
or magpie plugin, and, for one with a bin, to add an MCP server under
Library → MCP servers (notPlugin);
- the host says the same, without a stack, for one already on the list.
Run: TestCommandOnlyPackageIsNoPlugin (magpie-x-search 1.2.0's real
package.json) fails without the change (Add = <nil>; with only host.js
reverted, the stack message), TestTaggedRepos with the real GitHub
package.json and npm latest of cyberElar/magpie-x-search fails without it
(listed), both pass with it; TestNotPluginKeepsPlugins (index.mjs, main,
exports, middleware, pi, a file stay plugins). go test -tags nogui
./internal/plugin under a temp HOME ok; go vet -tags nogui for darwin,
linux, windows. The built binary in a sandbox HOME: `magpie plugin add
magpie-x-search@latest` from real npm prints the new error, and
plugins/package.json no longer lists it.
Co-Authored-By: Claude <noreply@anthropic.com>
yetone