Arch Linux User Repository

This is complicated. Dev packages then will also get into the package, but they are not needed for app to work, so this will just waste user's space. Maybe I will find some workaround in the future.

@Hanabishi I believe you could just use npm prune --production command, as specified in the NPM documentation

Also here's the exact issue blocking me from upgrading to Electron 16 (I use the localStorage to hide the message about downloading the Discord client):

https://github.com/electron/electron/issues/31833

If it will be fixed, I believe you will be safe to update to it. Hopefully, they will fix it before they deprecate Electron 15 (I don't want to end up in the same situation Discord it, being on old and deprecated Electron version because one feature stopped to work and I haven't found any workaround for it).

I've updated the app to mitigate this issue and disable the conflicting feature with Electron 16+. You're free to use it if you really need to, but Electron 15 is still preferred for now (with Electron 16+, an orange popup will show to download the official Discord client – it's hidden in Electron 15 version).

I was reffering that to pipe (|) operator – I believe you wanted to use or (||) operator instead.

No, the pipe actually hides error messages which is pointless in this case.

Just in case, you may want to install devDependencies instead of ignoring TSC errors

This is complicated. Dev packages then will also get into the package, but they are not needed for app to work, so this will just waste user's space. Maybe I will find some workaround in the future.

If it will be fixed, I believe you will be safe to update to it.

Ok.

my other plans are to document a feature while building my app with Electron Forge to add build flags to my application.

Will be good to have some environment variable or such.

@Hanabishi also, if you're interested, my other plans are to document a feature while building my app with Electron Forge to add build flags to my application. I will also try to describe how to implement it in your own build environment. This way you won't need to maintain a patch and you will be able to build WebCord as a stable release.

Also here's the exact issue blocking me from upgrading to Electron 16 (I use the localStorage to hide the message about downloading the Discord client):

• https://github.com/electron/electron/issues/31833

If it will be fixed, I believe you will be safe to update to it. Hopefully, they will fix it before they deprecate Electron 15 (I don't want to end up in the same situation Discord it, being on old and deprecated Electron version because one feature stopped to work and I haven't found any workaround for it).

@Hanabishi thank you for your answer:

I don't think that's an expected behavior.

I was reffering that to pipe (|) operator – I believe you wanted to use or (||) operator instead. Even if this code works, I don't think it is correct by that mean ;). One case that I could think of to use pipe over or would be if it would give you a perfomance advantages, although I don't think piping is faster than using or statement XD.

Just in case, you may want to install devDependencies instead of ignoring TSC errors, in some cases that could cause a possible breakage when a package updates its minior/patch version and breaks something that WebCord depends on. Even through that's not very likely to happen, it happened at least once for me. And I'm really aware of people reporting the issues with my application for that reason, because it did built successfully in AUR. With the build errors, it is more likely that people will report it in AUR and if the upstream has been fixed for that change, you will only need to update your PKGBUILD.

It is used by splash screen. When removed, splash image breaks https://i.ibb.co/L9Zv6M6/image.png

Oh, I haven't thought about that while developing the splash site – thank you for noticing that, I'll fix that in the next update, be ready for that change. I believe there should be one place for an icon, which is hicolor, at least for my AUR package (-git ones). So yea, that's definitely a bug I haven't thought about, I'll probably go further then and adapt my code just in case I will need to either use in-app icon or ignore it at all (which is what happens for BrowserWindow-s, GTK handles there icon without any of my interaction; this is also the reason why DevTools icon works only when WebCord's icon is placed in hicolor directory).

I don't think you'll need to limit any of the dependencies there, especially NPM version.

This was just in case, to be closer to package.json as possible. Ok.

I don't think that's an expected behavior.

This is intended. The package omits all dev dependencies, inculding type definitions. TSC will emit type errors.
But, as you said, this is static package and source is pre-tested anyway. So this is just optimization of build process.

App icon doesn't need to be installed there.

It is used by splash screen. When removed, splash image breaks https://i.ibb.co/L9Zv6M6/image.png

Also, my thoughts about this PKGBUILD overall:

makedepends=('npm>=7' 'typescript>=4.3.4' 'typescript<5' 'git')

I don't think you'll need to limit any of the dependencies there, especially NPM version. Also, you could make a check whenever yarn is installed and use that instead (remember that PKGBUILD is nothing different than a BASH script that gets source-d).

provides=("${pkgname}=${pkgver}")

Not needed – see Arch package guidelines in Arch Wiki.

conflicts=("${pkgname}-bin" "${pkgname}-git")

I don't think that's needed either – it should be in conflict already with the packages, as webcord-git and webcord-bin should provide webcord and be with it in conflict already. You can leave that just to be safe through.

tsc | true (in build())

I don't think that's an expected behavior. First, remember that this means that you're piping the tsc output to the true command. Second, errors in TypeScript are there usually for a reason and it makes no sense for me to just ignore them – errors are the first sign that something's not right with either a code or dependencies. I would rather cancel the build to avoid the consequences with the possible breakage.

/usr/lib/${pkgname}/sources/assets/icons/app.png

App icon doesn't need to be installed there. You may want to just install it in hicolor directory so it can be themed. However other icons like the one used for the tray still needs to be installed.

My other thoughts are that this PKGBUILD is rather simple to the one I develop for the -git package – maybe it doesn't need to be that much dynamic as it is meant to work with the particular version of the application through.

@Hanabishi Electron 16 has a new bug that is the reason why my project is still at 15. Also note that I've updated the -git package so it should depend on the electron version from the PKGBUILD (although some wrappers may use electron15, at least for the build time – this is because it is there as a dependency in .SRCINFO).

As of the update notification, WebCord supports some enviroment variables while being packaged with Electron Forge – I may announce the WEBCORD_UPDATER var in the future updates so any package maintainers could disable it when publishing it through repositories (including AUR).

the user has to wait until the PKGBUILD is updated and gets annoyed by the "new version is out" message

The thing is, I want to make the message not that much annoying when users are using the End-of-Life WebCord versions (I'm only supporting the latest stable one and the one from master builds). My propose would be to limit the message occurrence at given hour, so it won't display any message when you recently restart an app.

Also, I maintain the -git package over the stable one as I believe it is quite stable anyway (or if not, the build should be aborted and app just won't update) – and I would like to hear feedback at least from some users before I release the stable versions for other platforms. This way I can update and patch bugs before releasing the binaries. Bugs in master are rather fixed in short time.

@he3als, because it supposed to be used here, by the developer design. Yes, major Electron updates can bring incompatibility (that's why Arch maintains multiple versions). So I don't want to be responsible for unintended breakage here.
You can ask the developer about updating it.