Updater: Channel file is a BAD design

[axetroy]

The name of this is awful idea

https://github.com/electron-userland/electron-builder/blob/28cb86bdcb6dd0b10e75a69ccd34ece6cca1d204/packages/electron-updater/src/providers/Provider.ts?_pjax=%23js-repo-pjax-container%2C%20div%5Bitemtype%3D%22http%3A%2F%2Fschema.org%2FSoftwareSourceCode%22%5D%20main%2C%20%5Bdata-pjax-container%5D#L29-L37

  private getChannelFilePrefix(): string {
    if (this.runtimeOptions.platform === "linux") {
      const arch = process.env.TEST_UPDATER_ARCH || process.arch
      const archSuffix = arch === "x64" ? "" : `-${arch}`
      return "-linux" + archSuffix
    } else {
      return this.runtimeOptions.platform === "darwin" ? "-mac" : ""
    }
  }

It's really really ugly

latest.yml
latest-arm64.yml
latest-linux.yml
latest-linux-arm.yml
latest-linux-arm64.yml
latest-mac.yml
latest-mac-arm64.yml

The most important is YOU CAN NOT CHANGE IT

Because you can only change the name of the channel, not its suffix

updater.setFeedURL({ provider: 'generic', url: 'http://example.com/', channel: 'latest' })

The checkForUpdates() is always send request to http://example.com/<channel><suffix>.yml

WHY NOT design with this or something like this

<channel>-win32-x64.yml
<channel>-win32-arm64.yml
<channel>-linux-x64.yml
<channel>-linux-arm64.yml
<channel>-mac-x64.yml
<channel>-mac-arm64.yml

even without any suffix, suffix will be desiced by user

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

[axetroy]

The simplest way to change without BREAKING CHANGE

diff --git a/packages/electron-updater/src/providers/Provider.ts b/packages/electron-updater/src/providers/Provider.ts
index 819c4a21..25369334 100644
--- a/packages/electron-updater/src/providers/Provider.ts
+++ b/packages/electron-updater/src/providers/Provider.ts
@@ -13,6 +13,7 @@ export interface ProviderRuntimeOptions {
   platform: ProviderPlatform
 
   executor: ElectronHttpExecutor
+  customChannelName?: (channel: string) => string,
 }
 
 export abstract class Provider<T extends UpdateInfo> {
@@ -43,6 +44,7 @@ export abstract class Provider<T extends UpdateInfo> {
   }
 
   protected getCustomChannelName(channel: string): string {
+    if (this.runtimeOptions.customChannelName) return this.runtimeOptions.customChannelName(channel)
     return `${channel}${this.getChannelFilePrefix()}`
   }

updater.setFeedURL({
  provider: "generic",
  url: "http://example.com/",
  channel: "latest",
  customChannelName: (channel) => {
    return `${channel}_${process.platform}_${process.arch}`;
  },
});

Then the channel file will be

latest_darwin_x64.yml
latest_darwin_arm64.yml
latest_win32_x64.yml
latest_win32_ia32.yml
latest_win32_arm64.yml
latest_linux_x64.yml
latest_linux_arm64.yml

[axetroy]

Update: Why do I think this design is very bad?

Because these files are always deployed on the server, these operations often are not developers to do it.

They will be confused.

Q: "why are these files so confusing, I can't understand the relationship between them. Can you change to it more readable?"

A: No. These names are fixed and cannot be changed.

I have explained many times

[Jaifroid]

I think there's a wider issue with channels. Until recently, Electron Builder's auto-update would allow Electron apps that have an "Electron channel" in their package.json version number, e.g. v2.0.8-E (with E standing for Electron) to update via a release tagged on GitHub as v2.0.9 (with no -E). However, recently this has stopped working, and the app blocks such updates, forcing the app to stay only within its channel.

This is poor channel design, as it should be possible (ideally optional) for upgrades from a sub-channel to a non-channel. But the relevant option is unfortunately auto-set by Electron-builder in the case of GitHub at least, and it does not seem possible to override it.

The problem is the hard-coding of what constitutes a channel. Auto-update only recognizes -alpha and -beta. I have to agree that this is suboptimal design. Not only are these hard-coded in English, but the app makes automated assumptions about them that fail if the channel names are not as expected.