Hardcoded PLUGIN_VERSION is stale in 2.0.11: permanent false-positive update notice and mislabelled sm_plugin_version on writes

[maglez]

Summary

PLUGIN_VERSION in src/config.ts is hardcoded and has drifted behind package.json. On main (and in the published 2.0.11 tarball) it still reads 2.0.10 while package.json says 2.0.11.

Because the update check compares that constant against the npm latest dist-tag, 2.0.11 permanently reports that an update to 2.0.11 is available. The notice cannot be dismissed by updating, because updating is already done.

Root cause

src/config.ts:8

export const PLUGIN_VERSION = "2.0.10";

package.json on main

"version": "2.0.11"

src/index.ts:171-174 feeds the stale constant into the update check:

const updateCheck = checkNpmUpdate(
  "opencode-supermemory",
  PLUGIN_VERSION,
  UPDATE_COMMAND,
);

checkNpmUpdate resolves registry.npmjs.org/opencode-supermemory/latest (currently 2.0.11), compares it to "2.0.10", finds a difference, and formatUpdateNotice renders:

Supermemory update available: v2.0.10 -> v2.0.11

Reproduction

1. Pin the plugin at the current release, e.g. in your opencode config: "opencode-supermemory@2.0.11".
2. Clear any older cache entry so 2.0.11 is genuinely installed.
3. Start opencode.

Observed: the v2.0.10 -> v2.0.11 notice appears on every session start.
Expected: no notice, since 2.0.11 is the latest published version.

Verified 2.0.11 is actually the loaded code, not a stale cache hit: the installed bundle's dist/index.js sha256 differs from 2.0.10's, and 2.0.11-only behaviour (the per-message <supermemory-recall> directive from the conditioned-recall change) is present at runtime. Both tarballs nonetheless carry the same PLUGIN_VERSION = "2.0.10", which is what makes the notice inescapable from the user side. Nothing in user configuration can suppress it.

Second impact: stored memories are mislabelled

This constant is not only cosmetic. src/services/client.ts:343 attaches it to every write as telemetry metadata:

sm_plugin_version: PLUGIN_VERSION,

So memories created by 2.0.11 are recorded server-side as originating from 2.0.10. Any analytics, debugging, or migration logic keyed on sm_plugin_version will attribute 2.0.11 traffic to the previous release. This will keep silently corrupting that field for as long as the constant is maintained by hand.

Suggested fix

Derive the version from package.json at build time rather than restating it, so the two cannot drift:

• inject it with a bundler define/replace (e.g. esbuild --define:PLUGIN_VERSION=... sourced from package.json), or
• generate src/version.ts in a prebuild step, or
• import package.json directly if the build target permits it.

Any of these makes the class of bug structurally impossible. A release-checklist item would prevent the next occurrence but not this class of error.

Minor, related

src/index.ts:33 sets the remediation command shown in the notice:

const UPDATE_COMMAND = "bunx opencode-supermemory@latest install";

That command is not runnable for users of the standalone opencode binary distribution, which embeds bun privately and puts no bun/bunx/node/npm/npx on PATH. Those users are shown an update instruction they cannot execute. Worth considering a runtime-agnostic phrasing, or pointing at the plugin-config route instead.

Environment

• opencode-supermemory 2.0.11, pinned explicitly and confirmed loaded
• npm latest dist-tag: 2.0.11
• opencode standalone binary install, macOS (arm64), no JS runtime on PATH

[Dhravya]

Really sorry, fix is underway!