diff options
Diffstat (limited to 'packaging/win/electron-builder.msix.yml')
| -rw-r--r-- | packaging/win/electron-builder.msix.yml | 82 |
1 files changed, 33 insertions, 49 deletions
diff --git a/packaging/win/electron-builder.msix.yml b/packaging/win/electron-builder.msix.yml index d3adad6..577e039 100644 --- a/packaging/win/electron-builder.msix.yml +++ b/packaging/win/electron-builder.msix.yml @@ -1,8 +1,22 @@ -# 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. +# Standalone electron-builder config for the "MSIX" Windows target: the +# bundled node + ffmpeg, packaged for Microsoft Store submission instead of +# NSIS. +# +# What the NSIS build does with scripts -- firewall rules, a Startup-folder +# launcher, a boot task, a PATH entry -- this package DECLARES in its manifest, +# and Windows creates it at install, carries it across updates and removes it +# with the package, all without an administrator prompt. Scripts could not do +# that job here: everything they write names the install folder, and a Store +# install lives in C:\Program Files\WindowsApps\MeshBay.MeshBay_<version>_..., +# which each update deletes. Measured on a real install (2026-10-08): +# - firewall: build/appx-manifest.xml declares the node's rules; +# - at sign-in: build/appx-extensions.xml declares a startup task, off by +# default, that the node's CLI switches (`meshbay-node autostart`), +# for the app's Node page and a terminal alike; +# - `meshbay-node` in a terminal: an execution alias, also in that file; +# - at boot, before anyone signs in: not offered. It needs a boot task, +# created elevated and left behind on uninstall; that is the .exe +# installer's job. # # Deliberately NOT layered onto package.json's `build` field, same reasoning # as electron-builder.light.yml: --config reads ONLY this file, so nothing @@ -42,33 +56,15 @@ win: 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. + # The node runtime as Full ships it, both executables: meshbay-node.exe + # (CLI, and what the app starts) and meshbay-nodew.exe (no console, for + # the startup task). No scripts: firewall.ps1, the service scripts and + # ensure-node-path.ps1 are the manifest's job here (see the top of this + # file), and main.js offers no service mode without service-mode.ps1. - 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 # The application's own licence, beside the app (Electron's LICENSE and # LICENSES.chromium.html are put next to the exe by electron-builder). - from: ../../LICENSE @@ -99,26 +95,14 @@ appx: - 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. + # Execution aliases need Windows 10 1709; 1809 is the oldest still + # serviced. electron-builder's default (10.0.14316.0, for both) predates both. + minVersion: 10.0.17763.0 + maxVersionTested: 10.0.26100.0 + # The stock template plus the package-level firewall rules. + customManifestPath: build/appx-manifest.xml + # The startup task and the execution alias. Not addAutoLaunchExtension: + # that one always starts the package's main executable, the Electron shell, + # where "at sign-in" means the node. customExtensionsPath: build/appx-extensions.xml showNameOnTiles: false |