Plugin manager offers an "update" to an older code line: the version check ignores dist-tags.latest

[xinspark]

What happens

The plugin manager's update check treats any published version with a greater semver as an update. A package that renumbered its releases downward (0.12.3 -> 0.2.0) therefore shows a false update, and offers a downgrade to code that is weeks older.

Real case (plugin dsh-win-pwsh7, DSH kernel 0.2.2-rc.1, desktop shell 2.0.22-next):

• installed: 0.2.6; the registry's dist-tags.latest is also 0.2.6
• the plugin page showed "可更新到 0.12.3" (published 2026-10-19, 17 days earlier) with an update button per old version
• 0.12.3 is the previous numbering line: it predates 0.2.0, carries no Windows UTF-8 console bridge, and its engines.dsh is one the running build refuses

Where it comes from

@deepseek-ai/dsh-plugin-manager/lib/types/versions.js:26-28

return listed
    .filter((version) => typeof version === 'string' && semver.valid(version) !== null && semver.gt(version, installed))
    .sort(semver.rcompare)

The pnpm view <name> versions time dist-tags --json answer does carry dist-tags; newerVersions() reads them only to label the rows (tags), never to decide what is newer. The client then picks the first installable, non-deprecated, non-prerelease entry (dsh-client-ui-plugin-manager/lib/client.js:2905-2908) and uses it for both the card tag (:5898) and the page headline (:5644).

Why it matters

• Semver ordering is not publish ordering. Any renumbering or line reset makes the check offer older code as an update.
• For a plugin that pins engines.dsh, the "update" can be a build the running host rejects, and an incompatible bundle is skipped silently at boot, so after clicking update the user can end up with no plugin at all.
• The registry already states its intent in dist-tags.latest; the check has the field and ignores it.

Suggested fix

1. Prefer dist-tags.latest when it resolves to a valid version: an update exists when semver.gt(latest, installed); other versions stay reachable through the "install a specific version" path.
2. If latest is missing, at least drop versions whose time[version] is earlier than the installed version's publish time, which is the direct "not newer, older" signal the answer already contains.
3. Optional: when a candidate's publish time predates the installed version's, label it as an older line so the update button carries a warning instead of a silent downgrade.

Workaround used

Unpublished the old 0.12.x versions, which removes them from versions and clears the false prompt. Not every author can or should do that, and the next renumbering reproduces the bug.

Environment: Windows 11, DSH 0.2.2-rc.1, plugin manager read from registry.npmjs.org.

[jjjjjjjjnnjnn]

One data point on the update prompt: the prompt offering 0.12.3 disappeared because the author unpublished that version from npm, not because the plugin manager resolved the semver-versus-publish-order comparison.

Registry probe readings against target runtime 0.2.2-rc.1:

• dsh-win-pwsh7@0.2.6 -> admitted (1 item: engines.dsh >=0.2.1-rc.3 <0.3.0-0)
• dsh-win-pwsh7@0.12.3 -> unreadable (version 0.12.3 is not on the registry)
• Registry dist-tags: latest = 0.2.6

The installed 0.2.6 build is latest and satisfies declaration-layer admission under 0.2.2-rc.1. The update notification vanished only because 0.12.3 no longer exists on the registry. Relying on authors to unpublish abandoned release lines is not an option available to every ecosystem maintainer, and the manager comparison still treats higher semver numbers as upgrades regardless of release sequence.

What you can do:

• Keep dsh-win-pwsh7@0.2.6 installed; its declaration matches 0.2.2-rc.1.
• If a similar prompt reappears for other plugins, verify whether the offered version is an unmaintained legacy line before upgrading.

I maintain dsh-triage, the read-only tool that produced these numbers.

This reads published manifests from npm, not your machine. Declaration-layer admission does not prove runtime health.

Recompute artifact: https://github.com/jjjjjjjjnnjnn/dsh-triage/blob/main/data/results/remedy-probe-2026-11-05T08-37-26-770Z.json (sha256 596acd45466e41cef22f4e582c859d88dbadad8acc552e43c99112d45fc83326)

[xinspark]

Thanks for the independent numbers — they match the report, and one clarification keeps the record accurate.

The 0.12.3 prompt disappearing is the unpublish mitigation I listed under "Workaround used", not a fix from the manager. That means the probe readings describe the post-unpublish state: latest = 0.2.6, 0.2.6 admitted, 0.12.3 unreadable because it is gone. Useful as a repro artifact, but by construction it cannot distinguish "the comparison is correct" from "there is nothing older left to compare".

The bug itself is unchanged: newerVersions() filters semver.gt(version, installed) and reads dist-tags only for row labels. The next downward renumbering reproduces the prompt, and for packages other people already depend on, unpublishing is not a remedy we should normalize — deleting published history is a one-off cleanup, not a fix.

So the ask stands: prefer dist-tags.latest when it resolves, and use publish time as the fallback ordering signal.

[jjjjjjjjnnjnn]

Your correction is fair: because our earlier probe ran after the 0.12.x line was unpublished, that reading cannot distinguish a correct comparison from having nothing older left to compare. In our own artifact, dsh-win-pwsh7@0.2.6 now reads as no-newer, measuring your point with the same tool.

In @deepseek-ai/dsh-plugin-manager@0.2.2-rc.1, the comparison lives in lib/types/versions.js:18-37, where newerVersions() checks semver.gt. The data needed to fix this is already in the returned object (publishedAt from time, and tags from dist-tags). In addition, update() in lib/types/index.js:742 independently requires semver.gt(version, from), so a list-only fix leaves the explicit-version path unchanged.

Preferring dist-tags.latest alone has a measured counterexample: in a sample of 60 packages matching dsh, 22 have latest below their highest published version (such as @deepseek-ai/dsh). We suggest a narrower rule instead: treat a candidate as an update only when semver.gt(candidate, installed) and time[candidate] > time[installed]. Versions with higher semver but earlier publish timestamps can be treated as an older line rather than offered as an update.

Our sample of 60 packages found 0 live instances of the trap: the mechanism in code is real, but a live reproduction needs both lines to stay published, and our sample did not find one.

Recompute: node scripts/record_update_trap.mjs --stamp 2026-11-05T10:46:00.000Z --search dsh --limit 60

These readings are published metadata from npm, not your machine. Declaration and version metadata do not prove runtime health.

[aturzone]

Confirmed in source on current master fcc0ad4621, and fixed with the registry fields the answer already carries.

Mechanism. packages/boot/plugin-manager/src/versions.ts newerVersions() filtered by semver.gt(version, installed) and sorted semver.rcompare; dist-tags were read only to label rows. listVersions() returns that order and the client installs the first accepted entry, so a downward renumbering turns an older published line into the default update. The reported chain is exactly that.

Patch — branch: https://github.com/aturzone/deepseek-harness/tree/fix/plugin-manager-update-line, commit e80914d279:

1. A valid dist-tags.latest that is not greater than the installed version now means "no update" — the registry's own current-line statement outranks semver ordering.
2. When latest is absent, candidates whose publish time predates the installed version's publish time are dropped (the direct older-line signal).
3. The tagged latest sorts first; remaining newer versions stay in the list, so the version picker keeps working.

I deliberately did not collapse the list to only latest (your suggestion 1's strict form): hiding every other newer version would change the version-picker UX. If maintainers prefer that stricter shape, it is a three-line change — the guard and time filter are the correctness part.

Evidence. Three regressions fail on the old logic and pass after:

• renumbered line: installed 0.2.6, versions [0.12.3, 0.2.6], latest: 0.2.6 → old offered 0.12.3, now [];
• latest-first with a predating candidate: installed 0.2.6, candidate 0.12.3 published 2026-10-19 before the 2026-11-04 installed build → dropped, 0.2.7 remains;
• no latest tag: publish-time fallback keeps only genuinely later publishes.

packages/boot/plugin-manager/tests → 435 passed; three real-Git install tests fail identically with my change stashed (sandbox network), so they are pre-existing; pnpm run typecheck 5/5 gates; Oxlint clean.

One note: the guard uses the installed version's publish time from the same time map. If a profile installed a version the registry no longer lists (or patched locally), that time is unknown and the filter falls back to the old semver behavior — the latest guard still covers the common renumbering case.

[aturzone]

Quality follow-up on the same branch (tip moved to 0c43a2b89e): a coverage self-review of the changed file found the comparator that pinned dist-tags.latest inside sort() was only partially ordered and left branch coverage short of this repo's per-file 100% gate.

The ordering is now sort(semver.rcompare) followed by moving a present latest to the front (a total order), and three regressions cover a mid-line latest, a candidate published without a recorded time while the installed time is known, and a single-version answer printed as a string. packages/boot/plugin-manager/src/versions.ts reports 100% statements/branches/functions/lines on its own spec; the full package suite is 438 passed with only the three pre-existing sandbox-network Git tests failing.