As of commit b49b623a ("discord: use distro layout for stable on Linux", PR #515876),
Discord's launch script runs a `discord-stage-modules` script defined in `linux.nix`,
which creates symlinks from `~/.config/discord/<version>/modules/<module_name>`
to the corresponding Nix store paths so Discord can find them.
It checks whether this has already been done by looking for `installed.json` in the same dir,
which it also creates, and skips link creation if so.
However, since the dir is indexed by Discord version number,
the links are not refreshed when opening a new build of Discord with the same version number as an older build.
If the old build is then GC'd, the links break and Discord fails to start
with an error such as `Cannot find module 'discord_desktop_core'`.
Deleting the module folder entirely allows for it to be recreated and for Discord to start without issue.
This problem and solution are attested on the wiki, albeit with less explanation:
https://wiki.nixos.org/wiki/Discord#Crash_on_start-up.
The package fix is to delete and recreate the `modules` folder on each launch,
as it is small and does not contain any data meant to persist between launches:
it has only the module links, `installed.json`, and a `pending/` download directory
recreated by Discord's updater on startup.
The fix ensures that the links always point to the Nix store of the build of Discord being run,
so they will not be broken by GC.
Assisted-by: Claude Fable 5 in Claude Code
(cherry picked from commit 8f5437cf20)
This is very similar to how the aliases.nix overlay can be removed to
prevent usage of them in Nixpkgs itself, but this config attribute
allows preventing use of other existing attributes in Nixpkgs.
Needed for a follow-up commit.
(cherry picked from commit 7cc4d7dea8)
A package failing an automatic problem (of which there's currently only
one) is rare. A package having meta.problems specified is even rarer.
Inlining the getName call to its two usages saves a thunk in the vast,
vast majority of cases, and I consider it to be worth it.
(cherry picked from commit 85e32af8ef)
kind and name are more likely to stay the same. Doing this allows us to
cache the kind and name when calling the handler for a problem.
(cherry picked from commit 41bafcbc34)
The stats may be lying to me when they say that this saves 1.86% of
attrset lookups, and `?` may just not be accurately tracked. But at
worst, performance will stay the same, since the check will fail for all
non-broken packages. And who knows, maybe it does help, by nature of not
checking the value!
(cherry picked from commit 753e43c931)
