maker-flatpak: documented config requires patching unmaintained upstream deps; recommend doc disclosure or marking experimental

[gesslar]

Summary

The flatpak maker page presents the maker as a working, supported configuration. In practice, building a flatpak today against current freedesktop SDKs requires patches to upstream packages that haven't shipped releases in years. Users running electron-forge make get an opaque flatpak-builder failed with status code 1 with no in-product path to the root cause — discovering it requires DEBUG=* and reading installer source.

Concrete blockers shipping a flatpak with the documented config

1. @malept/electron-installer-flatpak doesn't forward workingDir / cleanTmpdirs to the underlying bundler — silently ignored. No incremental builds, no inspectable build tree. Filed: malept/electron-installer-flatpak#131.
2. The same package pins zypak to tag v2021.02, whose Makefile uses clang++, which the freedesktop SDK doesn't ship. Default builds fail with make: clang++: No such file or directory. zypak itself fixed this upstream years ago (current tag v2025.09 uses g++). Filed: malept/electron-installer-flatpak#132. Related downstream symptom: #2805.
3. Adjacent context, same shape on a sibling maker: electron-userland/electron-installer-redhat#343 / #344. @electron-forge/maker-rpm depends on an installer that hasn't shipped since Feb 2023 and now requires a patch (PR Unable to Build for Windows on Linux, Error: "Can't find custom attr constructor image" #344, open since Jan 2025) to work on Fedora 41+. Forge users hit this on npm run make with no warning.

@malept/electron-installer-flatpak last released v0.11.3 in May 2021 (almost 5 years ago). electron-installer-redhat last released in Feb 2023. Both are effectively unmaintained.

The actual gap

Forge doesn't own those packages and isn't on the hook to fix their bugs. But Forge chose them as the implementations behind first-party @electron-forge/maker-* packages, ships them under the @electron-forge/ npm scope, and documents them on electronforge.io. That makes monitoring fair to ask for, even when fixing isn't.

The error reporting is also fully opaque through the chain (forge → @malept/electron-installer-flatpak → @malept/flatpak-bundler → flatpak-builder → make → clang++ not found). Nothing surfaces beyond "status code 1." A user can't discover the cause from the error, and they can't discover it from the docs either. That's the bug under the bug.

Recommendations (in order of preference)

1. Disclose on the maker page. A short note explaining the maker depends on @malept/electron-installer-flatpak (and transitively refi64/zypak), that both have known issues requiring patches in current build environments, with links to upstream. Costs nothing, saves every downstream user the same multi-day investigation.
2. Mark the maker as experimental / community-maintained in the docs nav.
3. Surface chain errors better. At minimum, document DEBUG=* on the maker page so users hitting "status code 1" know how to get a real error.
4. Remove the docs page until the upstream chain is healthy. "We don't currently support flatpak; here are community alternatives" is a more honest answer than the current implicit "this works."

Happy to send a docs PR for (1) if maintainers are open to it.