appId: ai.multica.desktop productName: Multica directories: buildResources: build files: - "!**/.vscode/*" - "!src/*" - "!electron.vite.config.*" - "!{.eslintignore,.eslintrc.cjs,.prettierignore,.prettierrc.yaml,dev-app-update.yml,CHANGELOG.md,README.md}" - "!{tsconfig.json,tsconfig.node.json,tsconfig.web.json}" protocols: - name: Multica schemes: - multica asarUnpack: - resources/** mac: entitlementsInherit: build/entitlements.mac.plist target: - dmg - zip # Hardcoded name avoids the `@multica/desktop-*` subdirectory that # `${name}` produces for scoped package names. # Naming scheme: multica-desktop---. # so the filename alone surfaces kind, version, platform, and CPU arch. artifactName: multica-desktop-${version}-mac-${arch}.${ext} # Notarize via notarytool. Requires APPLE_ID + APPLE_APP_SPECIFIC_PASSWORD # + APPLE_TEAM_ID env vars at package time. Non-mac contributors are # unaffected because `pnpm package` already requires the Developer ID # signing cert — notarization is a strict superset. notarize: true dmg: artifactName: multica-desktop-${version}-mac-${arch}.${ext} linux: # Override the Linux executable name to avoid leaking the scoped npm # package name (`@multica/desktop`) into the installed binary, the # `.desktop` file, and the hicolor icon filename. Without this override # electron-builder defaults `executableName` to the package `name`, # which after slash-stripping becomes `@multicadesktop` — producing # `/usr/share/applications/@multicadesktop.desktop`, # `Icon=@multicadesktop`, and # `/usr/share/icons/hicolor/*/apps/@multicadesktop.png`. The leading `@` # violates the freedesktop desktop-entry naming guidance, so GNOME / # Ubuntu fail to associate the running window with the `.desktop` entry # and fall back to the theme's default app icon (the Settings gear on # Yaru). Forcing `multica` makes every Linux identity slot agree and # matches `StartupWMClass=Multica` (productName-derived). executableName: multica # Pin StartupWMClass to the WM_CLASS Electron emits on X11. Electron # derives WM_CLASS from `app.getName()`, which reads the *packaged* # ASAR's `package.json` — `productName` if present, otherwise `name`. # PR #2437 assumed electron-builder.yml's productName fed app.getName() # directly; it does not. With our source package.json carrying only # `name: "@multica/desktop"`, packaged Electron emitted # `WM_CLASS=@multica/desktop`, which broke association with this entry # and reproduced #2515 on Ubuntu 0.2.31. The fix lives in two places # outside this file — `productName: "Multica"` on the source # package.json (so the ASAR carries it) and `app.setName("Multica")` # in the production branch of `src/main/index.ts` (belt-and-braces). # Keep `StartupWMClass: Multica` pinned here so any future drift in # those two anchors shows up as a diff against this declaration. # Verification on a real Ubuntu install: `xprop WM_CLASS` on a running # window prints `Multica` for both fields. desktop: entry: StartupWMClass: Multica # Point at pre-rendered hicolor sizes. electron-builder *can* generate # 16/24/32/48/64/128/256/512 from a single build/icon.png, but the # auto-generation silently shipped only the 1024×1024 source in our # v0.2.31 .deb (#2515 reproduces this) — leaving GNOME's hicolor lookup # with no usable size and falling back to the theme default. Shipping # the sizes from source removes the toolchain dependency entirely. icon: build/icons target: - AppImage - deb - rpm artifactName: multica-desktop-${version}-linux-${arch}.${ext} rpm: # Disable RPM build-id symlinks. Electron apps embed the upstream Electron # binary, whose GNU build-id is identical across every app shipping the same # Electron version (Slack, VS Code, Discord, ...). Without this, our RPM # would own /usr/lib/.build-id/ paths and collide with any other # Electron RPM already installed, breaking `dnf install` on Fedora/RHEL. fpm: - "--rpm-rpmbuild-define=_build_id_links none" win: target: - nsis artifactName: multica-desktop-${version}-windows-${arch}.${ext} publish: provider: github owner: multica-ai repo: multica # Align with our CLI release flow which pre-creates a *published* GitHub # Release via `gh release create`. The electron-builder default of # `releaseType: draft` conflicts with `existingType=release` and causes # uploads of the DMG/ZIP/blockmaps/latest-mac.yml to be silently skipped, # which breaks electron-updater auto-update on installed clients. releaseType: release npmRebuild: false