goofcord: 1.7.1 -> 2.0.1

[MiniHarinn]

Release: https://github.com/Milkshiift/GoofCord/releases/tag/v2.0.1
Diff: Milkshiift/GoofCord@v1.7.1...v2.0.1

Changes:

• Switched goofcord to Bun-based builds (removed pnpm/fetchPnpmDeps, build now uses bun run build and electron-builder from node_modules with -c.npmRebuild=false).
• Added a fixed-output node-modules derivation and wired it into the package via callPackage.
• Added a configurePhase to copy the prebuilt node_modules into the build tree.
• Patched shebangs for Bun/tsgo (node_modules/.bin and node_modules/@typescript/native-preview/bin) to avoid /usr/bin/env failures.
• Bumped Node to nodejs_24.
• Made Electron fuses work by copying electron.dist to a writable electron-dist and pointing electron-builder at it on Linux.
• Fixed icon install path to assets/gf_icon.png.
• Added runtime deps for venbind (libxkbcommon, libX11, libxcb, libXtst) and prefixed LD_LIBRARY_PATH in the wrapper.
• Switched platforms to lib.platforms.linux.

I’ve also noticed that this package hasn’t been updated for quite some time, and I’d be happy to help maintain it in the future. If the situation allows, I will open a follow-up PR to update the maintainer metadata (I currently have a pending PR that modifies maintainer-list.nix, which needs to be merged before my handle becomes available).

Things done

• Built on platform:
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• Tested, as applicable:
  • NixOS tests in nixos/tests.
  • Package tests at passthru.tests.
  • Tests in lib/tests or pkgs/test for functions and "core" functionality.
• Ran nixpkgs-review on this PR. See nixpkgs-review usage.
• Tested basic functionality of all binary files, usually in ./result/bin/.
• Nixpkgs Release Notes
  • Package update: when the change is major or breaking.
• NixOS Release Notes
  • Module addition: when adding a new NixOS module.
  • Module update: when the change is significant.
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other READMEs.

[nyabinary]

Can Venbind and Venmic be built separately instead of using the ones provided in the binary?

[MiniHarinn]

Can Venbind and Venmic be built separately instead of using the ones provided in the binary?

It seems that GoofCord doesn’t have instructions on how to swap in externally built Venbind/Venmic at runtime. Therefore, if we want to use system-built Venbind/Venmic, we’ll need to patch the project in some way to make it load system paths.

[nyabinary]

Can Venbind and Venmic be built separately instead of using the ones provided in the binary?

It seems that GoofCord doesn’t have instructions on how to swap in externally built Venbind/Venmic at runtime. Therefore, if we want to use system-built Venbind/Venmic, we’ll need to patch the project in some way to make it load system paths.

The native modules are imported from "/assets/native", so if you place them there with correct filenames it should just work according to Goofcord developers.

[MiniHarinn]

Thanks, I will look into that today.

[MiniHarinn]

So far, this has somehow taken my entire day. But I got it working by building both Venbind and Venmic on Nix and ditching the prebuilt binary completely. That said, this approach comes with a significant downside due to the multilayered dependencies we have to vendor and manage, as you can see in the venmic-addon.nix file, along with some fragile patching that could break if upstream changes their CMakeLists.txt. This also means that future update attempts will be more difficult to carry out.

I’d like to know your opinion on this implementation so I can adjust as needed.

[MiniHarinn]

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 487177
Commit: a64c08c3a233e3753a7efd9391121f651e195dfb (subsequent changes)
Merge: 800c948eec7188412eb60ddfe2c1b380dce33f86

Logs: https://github.com/MiniHarinn/nixpkgs-review-gha/actions/runs/21828792518

---

x86_64-linux

✅ 1 package built:

• goofcord

---

aarch64-linux

✅ 1 package built:

• goofcord

---

x86_64-darwin

✅ No rebuilds

---

aarch64-darwin

✅ No rebuilds

[nyabinary]

So far, this has somehow taken my entire day. But I got it working by building both Venbind and Venmic on Nix and ditching the prebuilt binary completely. That said, this approach comes with a significant downside due to the multilayered dependencies we have to vendor and manage, as you can see in the venmic-addon.nix file, along with some fragile patching that could break if upstream changes their CMakeLists.txt. This also means that future update attempts will be more difficult to carry out.

I’d like to know your opinion on this implementation so I can adjust as needed.

Seems fine to me, will other packages be able to use venbind and venmic as well, just to be discord client agnostic. Also anything that the developer of Goofcord that can make your life easier with maintaining this?

[yipfluoric]

From what i can see, you could most likely use the venmic and venbind this has for other clients. other than the aforementioned CMakeLists.txt, the only issue i can see is that, this would most likely require other clients to be built by source too. easiest one to do this on would probably be legcord (goofcord is based on this, but unsure if it uses these two because it uses shelter) but past that it may get harder to do afaik.

[MiniHarinn]

Seems fine to me, will other packages be able to use venbind and venmic as well, just to be discord client agnostic. Also anything that the developer of Goofcord that can make your life easier with maintaining this?

The problem isn’t Goofcord itself. Instead, it’s Venmic, which seems to have most of the dependencies that we need to vendor and manage. It looks like Goofcord developers expected prebuilt Venmic and Venbind, so they didn’t pay much attention about us building those addons on our own, which is fair enough.

[nyabinary]

This looks good, well at least until #376299 is finished and merged :), do you mind adding yourself as a maintainer as well?

[MiniHarinn]

This looks good, well at least until #376299 is finished and merged :), do you mind adding yourself as a maintainer as well?

Thanks, I’ll add myself as a maintainer.

[Milkshiift]

Hi, GoofCord developer here. First off, thank you for spending your time on this.
I've been honing the build process only for my local environment and the release GH actions, so it's probably not perfect for packaging. If there is anything I could do for the next release to make this process easier I would gladly look into it.

[MiniHarinn]

Hi, GoofCord developer here. First off, thank you for spending your time on this. I've been honing the build process only for my local environment and the release GH actions, so it's probably not perfect for packaging. If there is anything I could do for the next release to make this process easier I would gladly look into it.

First of all, thanks for joining us here (that’s big! I didn’t expect to meet Goofcord’s dev here). I understand your focus on local builds and GHA-based build jobs, but here are some of my recommendations that will hopefully make packaging in Nix much easier:

• We could introduce some environment variables like GOOFCORD_VENMIC_NODE and GOOFCORD_VENBIND_NODE, or even GOOFCORD_NATIVE_DIR, so that in Nix we can simply use these environment variables to point to the Nix-build venmic and venbind instead of rewriting node_modules/.../prebuilds.

Other than that, in my opinion, it’s mainly about building venmic and venbind themselves, which isn’t really related to Goofcord’s build procedure.

Feel free to let me know if I’m wrong or if you have better ideas! Btw what do you think @nyabinary.

[Milkshiift]

Added the environment variables in Milkshiift/GoofCord@92e7270
GOOFCORD_VENMIC_PATH and GOOFCORD_VENBIND_PATH can now be set to the locations of the .node files.

You can also pass the --skipTypecheck argument to the build script to avoid patching tsgo.

[MiniHarinn]

Thanks for the implementation. I will open a follow-up PR after Goofcord releases a new version (including these changes). As of today, the commit is not tagged in Git yet.

TL;DR: This PR is ready to merge; a follow-up PR will be opened.