It would be great if electron-packager could support AppImage as a target for Linux. AppImage is a distribution-agnostic format for distributing Linux applications.
For example, it would be great if we could generate an AppImage from, e.g., https://github.com/Thomas101/wmail/blob/master/package.json
electron-builder already has AppImage support but some projects use electron-packager rather than electron-builder.
Duplicates #33 ? https://github.com/electron-userland/electron-packager/issues/33#issuecomment-163365713
Similar to #33, providing installers (or OS-specific packages in this case) is outside the scope of electron-packager.
I think this is a misunderstanding. AppImage is not an "installer", rather it is the direct equivalent of an ".app.dmg" in macOS. It is an executable file that runs directly on most Linux distributions without the need for installation.
The stated purpose of electron-packager is to "Package and distribute your Electron app with OS-specific bundles (.app, .exe etc)". AppImage is exactly such a bundle format for Linux.
Please reconsider.
In my opinion, the main problem with your argument is that upstream Electron already provides an Electron.app template for us to customize for your app, so all we're doing is replacing values (and files, for example the icon). This is true of all of the platform/architecture combinations. The only extra processing step that we do is create ASAR archives, and even that is outsourced to the asar module.
_(Also, we don't create .dmg files, electron-builder does, but I suspect that was just a typo on your part.)_
Adding AppImage support just doesn't make sense given the current architecture of Electron Packager.
Adding AppImage support just doesn't make sense given the current architecture of Electron Packager.
In my experience, Electron projects either use electron-builder or Electron Packager, where the former can do AppImage and the latter can't. This makes some projects consider to switch from the former to the latter.
@malept What exactly is it about the current architecture of Electron Packager that leads to "Adding AppImage support just doesn't make sense"?
@probonopd This is from me not @malept but I see Electron Packager and targets such as AppImage, MSI, EXE and other such build results as separate goals. Electron Packager's only goal is taking your code and packaging it into a generic folder that will run on the given platform. Supporting targets like AppImage is the role of tools such as electron-installer-* modules, electron-builder or electron-forge. It is separation of concerns IMO 馃憤
Tbh what @malept said is pretty much on point
Similar to #33, providing installers (or OS-specific packages in this case) is outside the scope of electron-packager.
@MarshallOfSound thanks for the explanation, that clarifies it for me. So you are saying one can use a combination of Electron Packager and electron-builder?
@probonopd electron-builder made the decision a long time ago to stop using electron-packager internally (wasn't really paying attention when that happened so not sure why). But electron-forge does use -packager internally and can use the AppImage target from -builder if that's the user preference.
And I believe you can use -packager and -builder together using the Electron Builder "pre-packaged" target.
Basically there are options for everyone 馃憤
So you are saying one can use a combination of Electron Packager and electron-builder
Yes. Please see https://github.com/electron-userland/electron-builder#pack-only-in-a-distributable-format
electron-forge does use -packager internally and can use the AppImage target from -builder if
Most helpful comment
I think this is a misunderstanding. AppImage is not an "installer", rather it is the direct equivalent of an ".app.dmg" in macOS. It is an executable file that runs directly on most Linux distributions without the need for installation.
The stated purpose of electron-packager is to "Package and distribute your Electron app with OS-specific bundles (.app, .exe etc)". AppImage is exactly such a bundle format for Linux.
Please reconsider.