Is this a replacement of Squirrel or user can choose modes?

user can choose modes?

RFC says that the updater will support both, msix support in the autoUpdater API will enable only when running in a windows package environment

I.e. dev chooses, ship a squirrel exe, an msix, or both for fun

The intention here is to first propose it as an alternative updater solution without explicitly discussing the future of Squirrel.Windows in Electron since it's a bit out of scope.

IMO without a clear path for apps to migrate from Squirrel.Windows -> MSIX, I think there's no path to actually removing it from Electron.

This is an excellent proposal, and I think it covers a lot of what one would need for authoring a net new app using MSIX as a delivery mechanism. I think the decisions are reasonable and easy enough to build on.

I don't have enough context to address the Squirrel comments as my experience with MSIX has been shoehorning it into a bespoke system that is made of some electron-builder, electron-updater, and electron-forge code all duck taped together. We're familiar enough with the updater parts that we don't need to treat them as a black box and probably can't give useful feedback on that side. If anything, maybe I could open source some of the extra gate checks I'll be building around electron-updater's autoUpdater event handlers in app.

For our purposes we'd be adapting an existing build/deploy/upgrade stack so it would be useful to know how modular the proposed delivery would be: where would the code for the windowsPackagedApp namespace live? Would it be baked into the Electron core or a closely related library like electron-builder? For our use case we'd have a URL to a new MSIX and we'd just need the current app information and the ability to trigger an upgrade of the current app given the URL for the next version's MSIX package.

That is, if there's the option to have an open source lib with the windowsPackagedApp components readily available that can be decoupled from the Squirrel parts we could WindowsPackagedApp.updatePackage(...) in other stacks that'd be a good step. Squirrel as 'best practice' but with other approaches still possible.

It exceeds the scope of this document but it does stand to reason that the other big lift for meeting our needs at Notion are being able to build an appropriate AppxManifest.xml. If somewhere in the ecosystem there's a good library for building one those, it would go a long way. I've been making an attempt a data model that is more pragmatic ("I need microphone and custom protocol handler for my-app://") than just knowing which XML elements to throw into the file. Happy to factor mine out into something more general purpose and open source it as a standalone module for others to use to get bootstrapped.

In all, this addresses a good first chunk of what we need to get MSIX off the ground. We'll need a good documentation story and references on the other pieces (namely 1. Application Manifest XML files, 2. Knowing what is and is not reasonable to expect from an MSIX installation versus a traditional installer that can spray files and registry keys wherever it wants and 3. How to get up and running digitally signing the packages).

It stands to emphasize that an MSIX deployment is a huge lift: it's probably not an appropriate deployment mechanism for a hobbyist project unless it's very simple, it's more for larger enterprise installation cases.

@jasonbot thanks fort the feddback and great questions!

where would the code for the windowsPackagedApp namespace live? Would it be baked into the Electron core or a closely related library like electron-builder

The code needs to be inside electron core. For many purposes, developers will need to know at runtime of an app whether its packaged. For example, if you want to check whether Notifications are enabled for your app, you need to call the Window API for that differently. If you are not an MSIX packager app, you have to pass in the AUMID. If you are a MSIX packaged App then you shouldn't pass the AUMID, otherwise the API call fails. So there will be always slight differences in MSIX packaged apps.

For our use case we'd have a URL to a new MSIX and we'd just need the current app information and the ability to trigger an upgrade of the current app given the URL for the next version's MSIX package.

We are doing the same at Slack. But this will be a bit different. Instead of passing in the MSIX URL directly, we need to pass a URL to a json file, the same way how Squirrel on Mac works. We proposed this to align the API between Mac and Windows. That being said, I also thought about accepting either, the json format or a direct link to and MSIX. WHat are your thoughts @samuelmaddock

It exceeds the scope of this document but it does stand to reason that the other big lift for meeting our needs at Notion are being able to build an appropriate AppxManifest.xml. If somewhere in the ecosystem there's a good library for building one those, it would go a long way. I've been making an attempt a data model that is more pragmatic ("I need microphone and custom protocol handler for my-app://") than just knowing which XML elements to throw into the file. Happy to factor mine out into something more general purpose and open source it as a standalone module for others to use to get bootstrapped.

You will see that electron-windows-msix already has basic manifest generation capability. These capabilities could be extended. The question is how far. The MSIX schema is pretty big and there different namespaces depending on the version. It would be hard to cover all the possible use cases. At some point people will have to write their own manifest tailored to their needs. But there is definitely room to add more common option like protocol handler or startup tasks to the packager.

In all, this addresses a good first chunk of what we need to get MSIX off the ground. We'll need a good documentation story and references on the other pieces (namely 1. Application Manifest XML files, 2. Knowing what is and is not reasonable to expect from an MSIX installation versus a traditional installer that can spray files and registry keys wherever it wants and 3. How to get up and running digitally signing the packages).

You area absolutely right! There is a lot of things to consider and the capability around MSIX have changed alot with each Windows version.

It stands to emphasize that an MSIX deployment is a huge lift: it's probably not an appropriate deployment mechanism for a hobbyist project unless it's very simple, it's more for larger enterprise installation cases.

I'm curious which parts would be the hardest for a hobbyist project and how we could make it easier.