# Standalone electron-builder config for the "MSIX" Windows target: same
# feature set as Full (bundled node + ffmpeg), packaged for Microsoft Store
# submission instead of NSIS. The package carries none of installer.nsh's
# elevation logic: an AppX/MSIX install never elevates, by design. What is
# still unverified here is called out at each declaration below.
#
# Deliberately NOT layered onto package.json's `build` field, same reasoning
# as electron-builder.light.yml: --config reads ONLY this file, so nothing
# here can accidentally inherit or merge with Full's `nsis`/signing config.
#
# electron-builder's target key for this is `appx`, not `msix` -- this
# version (app-builder-lib's AppxTarget.js, checked against the installed
# ^26.15.3) has no separate `msix` target. It still produces a package
# Partner Center's MSIX upload flow accepts; the mismatch is a naming
# artifact of the tool, not a statement about which container format comes
# out. Re-check this against whatever version is installed if it is ever
# bumped -- do not assume the target name from memory.
#
# No CSC (code-signing cert) is configured for this target, and that is
# correct, not an oversight: per app-builder-lib's own
# windowsSignToolManager.js (computePublisherName), an AppX target built
# with no certificate configured is logged as "Windows Store only build" and
# left unsigned, with `publisher` written into the manifest as-is. Microsoft
# signs the package itself at publish time -- signing it here first would be
# pointless work, not extra safety.

appId: org.meshbay.client
productName: MeshBay

directories:
  # Full's own build lives in dist/, Light's in dist-light/ -- a third,
  # separate output dir so no two targets ever race on or clobber each
  # other's files.
  output: dist-msix

files:
  - src/**
  - ui/**

win:
  target: appx
  icon: build/icon.ico
  artifactName: "MeshBay-${version}.${ext}"
  extraResources:
    # Same bundle as Full (package.json's own build.win.extraResources) --
    # this target drops NSIS, not the node/ffmpeg runtime or the two service
    # scripts. service-mode.ps1 in particular still works unmodified: it is
    # invoked from main.js's winElevateServiceMode() on demand, from the
    # running (unelevated) app, not from an installer step -- that path
    # already existed before this target did (see "the other door" comment
    # in src/main.js) and needs nothing new here beyond the file being
    # present to find.
    - from: node-runtime
      to: node-runtime
      filter:
        - "**/*"
    - from: ../../packaging/win/firewall.ps1
      to: firewall.ps1
    - from: ../../packaging/win/service.ps1
      to: service.ps1
    - from: ../../packaging/win/service-mode.ps1
      to: service-mode.ps1
    # Full's own installer adds node-runtime\ to the per-user PATH at install
    # time (build/installer.nsh's customInstall) -- an unelevated HKCU write,
    # never blocked by the no-elevation rule this target is built around, but
    # MSIX has no install-time hook at all to run it from. main.js's
    # winEnsureNodeOnPath() calls this itself on first launch instead
    # (found missing by actually sideloading a build and checking, not
    # anticipated in the original plan).
    - from: ../../packaging/win/ensure-node-path.ps1
      to: ensure-node-path.ps1

appx:
  # --- Real values, from Partner Center's "App identity" page (App
  # management -> App identity), not chosen freely -- a mismatch here fails
  # Store validation outright rather than warning. publisherDisplayName is
  # "MeshBay" as Partner Center assigned it, NOT package.json's own author
  # company name ("MeshBay Team") -- AppXOptions.d.ts's default (company
  # name from app metadata) would silently pick the wrong one if this were
  # left unset, so it must stay explicit even though it looks redundant
  # next to `displayName`.
  identityName: MeshBay.MeshBay
  publisher: "CN=CE32BB0D-6B7C-4D3A-AA42-E259B778CAC9"
  publisherDisplayName: MeshBay
  applicationId: MeshBay
  displayName: MeshBay
  languages:
    - en-US
    - fr-FR
    - es-ES
    - pt-BR
    - zh-CN
    - ja-JP
    - de-DE
    - it-IT
    - nl-NL
    - pl-PL
  # Both are the "common" (general, non-restricted) capability group per
  # app-builder-lib's AppxCapabilities.js -- no special Store justification
  # needed, unlike the `rescap`-namespaced restricted ones. Matches
  # firewall.ps1's own rules, which are `-Profile Any` (private AND public
  # network). Whether Windows Firewall actually auto-exempts a full-trust
  # packaged app on the strength of these declarations -- eliminating the
  # elevation firewall.ps1 exists for entirely -- is an open item: verify
  # live before relying on it, the declaration alone only proves the
  # manifest is well-formed.
  capabilities:
    - internetClientServer
    - privateNetworkClientServer
  # windows.startupTask, the MSIX-native equivalent of the NSIS "at sign in"
  # mode's Startup-folder .vbs (main.js's WIN_STARTUP_VBS) -- but pointed at
  # the node daemon, not the Electron shell, which is what `addAutoLaunchExtension:
  # true` would do instead (it always targets the package's own main
  # executable, per AppxTarget.js's `executable` macro -- there is no config
  # switch to point it at a different bundled exe). build/appx-extensions.xml
  # declares that extension by hand for exactly this reason. Whether
  # Windows actually launches a *non-primary* bundled exe through this
  # mechanism is the other open item -- untested until sideloaded.
  customExtensionsPath: build/appx-extensions.xml
  showNameOnTiles: false