Add official Windows portable release artifact

[jabrailkhalil]

Request

Please consider adding an official Windows portable artifact alongside the current NSIS installer.

The current Windows release is distributed as vidbee-1.3.10-setup.exe, which is good for normal installs and auto-update support, but it does not cover no-install / USB / isolated-use scenarios.

electron-builder already supports a Windows portable target and exposes PORTABLE_EXECUTABLE_DIR, which VidBee can use to keep app data and downloads beside the portable executable.

Local test data

I tested VidBee v1.3.10 on Windows 11 Pro 10.0.26100 x64 using Windows Sandbox.

The installer was not executed; it was extracted and launched through a wrapper that redirected these paths into one portable folder:

• APPDATA
• LOCALAPPDATA
• USERPROFILE
• HOME
• XDG_CACHE_HOME
• XDG_CONFIG_HOME
• XDG_DATA_HOME
• DENO_DIR
• TEMP / TMP
• Electron --user-data-dir

Results:

• VidBee launched successfully in Windows Sandbox.
• Main window title observed: VidBee.
• Config files parsed successfully without UTF-8 BOM.
• Download path remained inside the portable folder.
• A bundled yt-dlp.exe smoke test downloaded a 991017-byte MP4 into Downloads\Videos.
• Host trace scan after closing Sandbox found 0 matches in the checked uninstall keys, startup keys, App Paths, Classes Applications, direct Software keys, common AppData/Program Files locations, Prefetch, scheduled tasks, services, and running processes.

This does not claim that Windows itself creates absolutely no metadata anywhere. It does show that the usual installer, Electron profile, updater, autostart, service, scheduled task, and common AppData footprints were not present in the checked host locations after the Sandbox test.

Suggested build config

Add portable to the Windows electron-builder targets while keeping the existing NSIS installer:

win:
  executableName: vidbee
  target:
    - nsis
    - portable

nsis:
  artifactName: ${name}-${version}-setup.${ext}
  shortcutName: ${productName}
  uninstallDisplayName: ${productName}
  createDesktopShortcut: always

portable:
  artifactName: ${name}-${version}-portable.${ext}

The current release workflow already uploads/publishes *.exe, so a generated vidbee-${version}-portable.exe should likely be included without large workflow changes.

Suggested portable-mode behavior

In portable mode, detected via PORTABLE_EXECUTABLE_DIR:

• Set Electron userData under <portable dir>/Data/UserData.
• Default downloads to <portable dir>/Downloads.
• Skip auto-updater initialization or make update UI/manual-update aware.
• Do not force autoUpdate: true from settings in portable mode.
• Skip protocol handler registration by default to avoid registry writes.
• Skip launch-at-login registration in portable mode.
• Keep yt-dlp/ffmpeg/Deno cache/temp paths under Data or Temp where possible.

Code-order note

settingsManager is currently imported and constructed at module import time in apps/desktop/src/main/index.ts. If portable mode needs to call app.setPath('userData', ...), that must happen before electron-store is constructed.

The clean fix may be either:

• initialize portable paths before importing/constructing settings, or
• make SettingsManager itself resolve portable paths before creating the store.

If this direction sounds acceptable, I can follow up with a PR implementing the portable target and portable-mode path handling.

[jabrailkhalil]

I opened an implementation PR for this proposal: #403

It adds the Windows portable release support and portable-mode path handling while keeping the existing installer behavior unchanged.