4.3.0-4.5.2-x64.AppImage fails to launch (for arch based distros)

[dreamsyntax]

Acknowledgements

• I have checked that there is no other issue describing the same or
  similar problem that I currently have, regardless if it has been
  closed or open.

• This bug affects Discord website.

• This issue is confirmed to be reproducible when WebCord is packaged
  on at least all three latest supported Electron major releases.

• This issue is reproducible in Chrome, Chromium or any
  Chromium-based browser, e.g Brave or Edge (please write in
  Additional Context which browser you have used if it is neither
  Chrome nor unmodified Chromium).

• There are no fixes done to master which resolves this issue.

• My issue describes one of the unstable and/or not fully implemented
  features.

• I have found a workaround to mitigate or temporarily fix this issue
  in affected releases (please write it in Additional context section
  below).

Operating System / Platform

🐧️ Linux

Operating system architecture

x64 (64-bit Intel/AMD)

Electron version

N/A

Application version

v4.3.0 - v4.5.2

Bug description

The 4.5.2-x64.AppImage in the releases page fails to launch.
Running the AppImage in cli reveals this message:

./WebCord-4.5.2-x64_6d40b5090f9f289d5c9224f28e1616c4.AppImage 
execv error: No such file or directory

I have verified the host is capable of launching other appimages with no issues.

Additional context

EndeavourOS, Cinnamon
The 4.2.0 app image can run successfully.
Every version after that can not. Tested:

$ ./WebCord-4.3.0-x64.AppImage 
execv error: No such file or directory
$ ./WebCord-4.2.0-x64.AppImage 
Cannot use import statement outside a module
[UPDATE] New application version is available! (v4.2.0 → v4.5.2)

I tested all releases since 4.2.0.

[SpacingBat3]

First of all, EndeavourOS is Arch-based AFAIK (I've never tried it out, I use raw Arch) and there are plenty of ways to install a native package for it to be integrated with the OS (see AUR and multiple repos providing WebCord, in case of repo list you can find that in the docs/).

Second, have you tried debugging the AppImage by mounting it (--appimage-mount) and running it that way or to compare how WebCord is executed right now vs before? I'm nowhere close to my Linux PC, so don't count on me checking this out.

Also, if the issue isn't due I've started using experimental FUSE3-based AppImage runtime in WebCord, this is likely an upstream issue since there's no development done on my side in WebCord (I maintain ReForged, but there's a reason it isn't a part of a WebCord's project, hence it would be more appropriate to distinguish the role of these projects and report problems respectively) around the AppImages, so it might be better to report this in ReForged instead.

[dreamsyntax]

Ah, I did not know the AUR versions were officially recommended, given the low ranking. I did not expect it to be a subpage under community repos, so my bad.

Second, have you tried debugging the AppImage by mounting it (--appimage-mount) and running it that way or to compare how WebCord is executed right now vs before? I'm nowhere close to my Linux PC, so don't count on me checking this out.

Doing this just has a blank resulting folder for me.

I confirmed it works fine on debian based like Linux Mint, so closing this since AUR is recommended instead of unsupported appimage.

[SpacingBat3]

Looks like this was an issue with your Linux env anyway, AppImages seem to work for me on Arch Linux. It should also be said I use the type2-runtime, which has some benefits over the latest stable AppImageKit release (e.g. support for multiple fuse versions, meaning there's no longer need to specifically install fuse2 in your Linux env) but I guess it could not be theoretically as stable. Personally, the type2-runtime runtime works for me fine and I had no issues with it.