multica/apps/desktop/electron-builder.yml

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-<version>-<platform>-<arch>.<ext>
  # 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).
  #
  # `multica-desktop` (not `multica`) so the deb/rpm/AppImage package never
  # installs this Electron binary as `/usr/bin/multica`. The Go CLI is a
  # separate artifact (see CLI_INSTALL.md) that agents and scripts expect
  # to find at `multica` on PATH; when both packages are installed on the
  # same box, a plain electron-builder default collides the two under one
  # name. Whichever installs later — or wins the PATH lookup order — silently
  # shadows the other. Hitting the Electron binary from a CLI call is the
  # worst failure mode: it exits 0 with empty stdout (its own Chromium flags
  # eat CLI args like `--output json`), which looks like a healthy CLI that
  # returned nothing rather than "wrong binary" (github.com/multica-ai/multica/issues/5481).
  # `StartupWMClass=Multica` (productName-derived) is unaffected by this
  # rename — it comes from `app.getName()`, not `executableName`.
  executableName: multica-desktop
  # 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/<hash> 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