WIP: adjust for newer versions that are based on pnpm workspace

Simon-Laux commented 3 weeks ago

I don't like the usage of s3 buckets, but I had no better idea. here the alternatives I considered:

storing pnpm cache in git makes the repo huge after just a few releases (every zipped pnpm store is minimum 178mb)
storing in git lfs has a similar problem
- doesn't make git slow, but only has 10gb in free plan on github
- git lfs is not supported by flatpak-builder out of the box
contribute to flatpak-node-generator to add support for pnpm
- not easily possible since pnpm store has completely different format compared to npm:
  - in npm all packages are stored in folders, in pnpm all their files are stored in one large content-addressable store -> I'm not sure if you could even generate a download manifest for this special format without adding extra steps.
  - So I think it would be best if pnpm could add support for installing packages from an npm cache or a similar cache that is easily constructed.
  - on that point see https://github.com/flatpak/flatpak-builder-tools/issues/383
- Cheat and just repackage the AppImage, like Modrinth
  - I'd rather not so this as we have some custom flatpak specific stuff like building core in flatpak builder, also it feels like it's against the spirit of transparency.
Install through some proxy that records all requests to a flatpak-builder manifest source list and later can replay them from a folder with the answers.
- ~~Too complex for now. still needs research if sth. close already exists.~~ -> #145
- The upside would be that this generice solution could also help with other future package managers (also for other languages).

The approach I now used means you either need your own s3 bucket to make a new version or I need to trust you and give you credentials to mine. Hopefully we can find a different file storage solution in the future. Though not a real problem currently until new contributors (besides me, muelli or nico) show up that want to change the desktop commit.