fix(desktop): restore linux launcher identity#31709
Conversation
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
Hona
left a comment
There was a problem hiding this comment.
Reviewed the packaging mechanics against the vendored app-builder-lib 26.15.2 source. The identity alignment (executableName / desktopName / StartupWMClass / icon basename) is correct and the compat launcher matches what electron-builder generates for prod (/opt/${sanitizedProductName}/${executableName}). No bugs found. One decision to confirm before merge (beta pins, inline) and two optional notes.
| protocols: { name: "OpenCode", schemes: ["opencode"] }, | ||
| publish: { provider: "github", owner: "anomalyco", repo: "opencode", channel: "latest" }, | ||
| rpm: { packageName: "opencode" }, | ||
| deb: { fpm: [legacyDesktopEntryFpm] }, |
There was a problem hiding this comment.
The compat launcher is prod-only, but the regression also affected beta: the regressed executableName: "opencode-desktop" was shared across all channels, and the deb/rpm launcher filename falls back to executableName, so regressed beta packages also installed /usr/share/applications/opencode-desktop.desktop. Beta users who pinned during the regression window will lose their pins on upgrade.
This may well be an acceptable tradeoff (short window, small audience, and a beta compat file would need a different Exec — /opt/OpenCode Beta/ai.opencode.desktop.beta — while colliding with prod's compat file at the same path, a conflict the regressed packages already had). If it's intentional, worth a sentence in the PR description; otherwise beta needs its own legacy entry.
There was a problem hiding this comment.
Resolved: maintainer decision is that launcher pin continuity is out of scope — no migration needed for beta (or anywhere). Not blocking merge. Optional follow-up: since pin migration is the compat launcher's only purpose, the opencode-desktop.desktop resource, the two fpm mappings, and the compat test could be dropped entirely to simplify the config — fine either way.
| icon: `resources/icons`, | ||
| category: "Development", | ||
| executableName: "opencode-desktop", | ||
| executableName: appId, |
There was a problem hiding this comment.
Optional hardening: the installed .desktop filename here comes from executableName only because linux.syncDesktopName defaults to false — the identity holds because executableName === appId and desktopName === appId + ".desktop" happen to agree. Setting linux.syncDesktopName: true derives the launcher filename from desktopName directly, which is the pattern the 26.15.x docs recommend, and app-builder-lib notes the default flips to true in v27 anyway. Same output today; just removes the implicit coupling. (Relatedly, the explicit StartupWMClass below is already the 26.15.x default when desktopName is set — harmless, fine to keep as documentation.)
| const module = await import(`./electron-builder.config.ts?channel=${channel.channel}`) | ||
| const config = module.default as Configuration | ||
|
|
||
| if (previous === undefined) delete process.env.OPENCODE_CHANNEL |
There was a problem hiding this comment.
Nit: the env restore runs after await import(...) without try/finally, so if the import throws, the mutated OPENCODE_CHANNEL leaks into subsequent tests. Only matters when the config module is already broken, but a finally would keep those failures isolated. Applies to both tests in this file.
Issue for this PR
Closes #31710
Regression context: #31571
Type of change
What does this PR do?
Restores the Linux desktop package identity after the Electron 42 packaging update in #31571 changed the installed executable, launcher, and icon basename to
opencode-desktop.The previous PR added
opencode-desktopto avoid electron-builder deriving an invalid AppImage executable name from the scoped npm package name@opencode-ai/desktop. This keeps the same path-safety property, but uses the channel app id (ai.opencode.desktop,ai.opencode.desktop.beta, orai.opencode.desktop.dev) so Linux desktop metadata lines up with the app id,desktopName,StartupWMClass, and hicolor icon basename.For prod, the visible launcher is
ai.opencode.desktop.desktopand referencesIcon=ai.opencode.desktop, so GNOME/KDE can associate the running Electron window with the installed launcher/icon.This also ships a hidden compatibility launcher at
opencode-desktop.desktopfor prod deb/rpm packages. Existing Linux dock pins that point at the short-livedopencode-desktop.desktopentry should keep launching the app while new installs use the canonical app id launcher.How did you verify your code works?
cd packages/desktop && bun test electron-builder.config.test.tscd packages/desktop && bun typecheckcd packages/desktop && OPENCODE_CHANNEL=prod bunx electron-builder --linux deb --config electron-builder.config.ts --publish nevercd packages/desktop && OPENCODE_CHANNEL=prod bunx electron-builder --linux AppImage --config electron-builder.config.ts --publish never.deband confirmed it contains:/usr/share/applications/ai.opencode.desktop.desktop/usr/share/applications/opencode-desktop.desktop/usr/share/icons/hicolor/.../apps/ai.opencode.desktop.pngbun turbo typechecksuccessfully.Screenshots / recordings
N/A - packaging metadata change only.
Checklist