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.
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.
yetone