joplin-desktop: build from source

[fugidev]

Motivation: Upstream doesn't provide binaries for aarch64-linux.

Part of #296939

I took inspiration from the respective packages on AUR and Flathub, which are also source builds.

Unfortunately, building this package is currently broken on Darwin with sandbox = true due to #415328 and #416077 (merged). Otherwise it does build and work. But because of this, I'd keep the bin package for now and automatically fall back to it on Darwin, to not cause any issues on existing user setups. (Any opinions on this are very welcome.)

On Linux, the included "Backup" plugin doesn't load for some reason. The AUR package has the same issue and it has been reported, see JackGruber/joplin-plugin-backup#92. It works on the flatpak tho, and on this package's Darwin build as well.
Edit: fixed

More usage testing is greatly appreciated, as well as any other reviews and comments. :)

@yajo you seem to be the only active maintainer of the current package, do you want to be added as maintainer here?

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• Nixpkgs 25.11 Release Notes (or backporting 24.11 and 25.05 Nixpkgs Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
• NixOS 25.11 Release Notes (or backporting 24.11 and 25.05 NixOS Release notes)
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md, pkgs/README.md, maintainers/README.md and other contributing documentation in corresponding paths.

---

Add a 👍 reaction to pull requests you find important.

[fugidev]

I reworked the plugin building to remove IFDs

[yajo]

I think this is simpler:

Suggested change

	rev = "refs/tags/v${finalAttrs.version}";
	tag = "v${finalAttrs.version}";

[fugidev]

It is, but it causes an error in nix-prefetch in the update script for some reason:

fetchFromGitHub requires one of either `rev` or `tag` to be provided (not both)

As a workaround rev = null can be added, or extending the nix-prefetch flags with --rev --expr null.

I thought the way I did it would be the simplest, but if using tag is much preferred then I can of course add one of these workarounds.

[yajo]

Did you make sure to add tag and remove rev? If so, nix-prefetch shouldn't fail.

Otherwise you can leave it as it is. It was just a suggestion based on code review, but if it is problematic then don't worry :)

[fugidev]

Yes, that's what I did. Must be a bug in nix-prefetch

[fugidev]

rebased and updated to 3.3.13

[fugidev]

I refactored buildPlugin.nix as suggested by @yajo.

[yajo]

I tested the app but got this:

Clicking restart in safe mode an launching again didn't help.

I'm not sure if this is actually a failure from the new build or from some configuration with local plugins...

[fugidev]

I'm not sure if this is actually a failure from the new build or from some configuration with local plugins...

Seems like you are running joplin-desktop 2.14.17 there for some reason, not this one

[yajo]

Ah! I tested the wrong PR. Now it worked!

About dialog provided this info FWIW

Joplin 3.3.13 (prod, linux)

Device: linux, 13th Gen Intel(R) Core(TM) i7-1360P
ID del Cliente: e7cf469d82bd47648320bf15c5040be8
Versión de la Sincronización: 3
Versión del Perfil: 47
Llavero Soportado: No
Alternative instance ID: -

Automatic Backlinks to note: 3.0.3
Freehand Drawing: 3.0.1
Link Graph UI: 1.5.0
Note Tabs: 1.4.0
Outline: 1.5.13
Quick Links: 1.3.2
Rich Markdown: 0.15.0
Toggle Editor Menu & Keyboard Shortcut: 1.0.1

[fugidev]

Rebased and updated to v3.4.6 (Note: that's actually a pre-release, but was updated to in #436033).

This required switching to yarn-berry_4 and some other minor changes.

Build tested on aarch64-linux and aarch64-darwin.

@r-vdp if the size of the vendored yarn.lock is an issue, we could instead store and apply the diff? That would be ~500KB, down from 1.6MB. Or we could try pruning it in the FOD and see if it breaks down the road.

[r-vdp]

Yeah, the only thing that's keeping me from merging this, is indeed the size of the vendored lock file.

Both of those options sound like they would improve the situation, but I don't know yarn enough to make the call on which approach would be better here.

[fugidev]

I changed it to store only the diff 👍
This way, I'm confident that it won't break ^^

[yuyuyureka]

fetchYarnBerryDeps should only download the tgz files and never try to compile anything or run build scripts of the dependencies. Your code mentions something about "would require unneccessary complexity to fix". Does that mean that with the original lockfile is broken with fetchYarnBerryDeps?
Otherwise, I wouldn't see the problem with fetching the dependencies for the entire workspace, and then only building a subset of the workspace.

[fugidev]

@yuyuyureka the issue is not with fetchYarnBerryDeps, that works just fine (I see where the confusion may come from; I only meant to specify the offlineCache's size difference for a rough idea on what portion of the deps is unnecessary).

yarn install is the step where some deps are apparently built from source, like sqlite (required for the desktop app) but also e.g. wasm-pack (which is not). And that would, afaict, require adding additional buildInputs (or otherwise workarounds) in order to not fail. Unless I've missed something ^^'

Edit: I'm taking another look at yarn workspaces focus. I couldn't get that to work before but maybe I've missed something (or it could be different with yarn 4).

[fugidev]

I got it working! No vendoring a modified lockfile needed anymore. I'm much happier with this.

For some reason I'm getting a hash mismatch for src on darwin now, that is very weird...

Edit: hash mismatch is resolved

[fugidev]

nixpkgs-review result

Generated using nixpkgs-review-gha

Command: nixpkgs-review pr 417048
Commit: 84cecfdf3cff39a731636cb201f2a167a5c223c4 (subsequent changes)
Merge: 39a7c5b823bdf782fc6edd7dae084eaadc324a9e

Logs: https://github.com/fugidev/nixpkgs-review-gha/actions/runs/17356630392

---

x86_64-linux

✅ 1 package built:

• joplin-desktop

---

aarch64-linux

✅ 1 package built:

• joplin-desktop

---

x86_64-darwin (sandbox = relaxed)

✅ 1 package built:

• joplin-desktop

---

aarch64-darwin (sandbox = relaxed)

✅ 1 package built:

• joplin-desktop

[r-vdp]

Suggested change

	rev = "refs/tags/v${finalAttrs.version}";
	tag = "v${finalAttrs.version}";

[fugidev]

See #417048 (comment)
What would be preferred in your opinion?

[r-vdp]

Ah, I didn't see that comment, sorry. The tag attribute is preferred because it avoids git getting confused when the repo contains a commit whose commit hash has the tag as a prefix, or a branch with the same name. And the refs/tags/ is also rather verbose.
So I would opt to add rev = null with a comment to explain why it is needed for now.

[fugidev]

rev = null in the derivation didn't work for some reason (it did back then). So I've added the workaround in the update script. Seems more fitting anyway when I think about it, since it's only relevant there.

[r-vdp]

Thanks for all your effort on this!

[fugidev]

Thank you and everyone else for reviewing and helping get this over the finish line! :)

[HHR2020]

This pr makes my joplin scale 4x when NIXOS_OZONE_WL is set.

[fugidev]

@HHR2020 it scales correctly and just the same with or without NIXOS_OZONE_WL set for me (1.5x scale on sway). You should create an issue, maybe others have the same problem?

[ajs124]

This seems to have introduced a runtime dependency on nodejs. Is there any way to avoid this?

[fugidev]

This seems to have introduced a runtime dependency on nodejs. Is there any way to avoid this?

Can you elaborate what you mean by that? And is that not the case for other (source-built) Electron applications? I can look into it if you give me some pointers :)

[ajs124]

What I mean is that this package depends on the nodejs package, which has quite a large closure size.
This isn't normal, no. nodejs should just be a build-time dependency.

If we compare the following:

$ nix-store -q --tree /nix/store/46xgz72mr2ppk40sd9crn9jcpsqbc31g-element-desktop-1.11.112|grep nodejs
[nothing]

with

$ nix-store -q --tree /nix/store/03fmf4hyy77s28kyfn6ak09dsp70jism-joplin-desktop-3.4.12|grep nodejs                                                                                                    
├───/nix/store/1x276grqkqal97vbf7xrna218jr2kv84-nodejs-22.19.0-source
├───/nix/store/r4557ald6zn4dzmvgh8na9vwnwzgrjgc-nodejs-22.19.0
│   └───/nix/store/r4557ald6zn4dzmvgh8na9vwnwzgrjgc-nodejs-22.19.0 [...]
$ nix path-info --recursive --closure-size --human-readable /nix/store/1x276grqkqal97vbf7xrna218jr2kv84-nodejs-22.19.0-source
/nix/store/1x276grqkqal97vbf7xrna218jr2kv84-nodejs-22.19.0-source        474.3M
$ nix path-info --recursive --closure-size --human-readable /nix/store/r4557ald6zn4dzmvgh8na9vwnwzgrjgc-nodejs-22.19.0
[…]
/nix/store/r4557ald6zn4dzmvgh8na9vwnwzgrjgc-nodejs-22.19.0               208.2M

This is likely because something in the build references this, but I'd assume/hope this isn't actually needed at runtime.

[fugidev]

This is due to shebangs and other references to nodejs in the node_modules inside app.asar:

$ grep -lr /nix/store/r4557ald6zn4dzmvgh8na9vwnwzgrjgc-nodejs-22.19.0 
node_modules/rimraf/bin.js
node_modules/tar/node_modules/mkdirp/bin/cmd.js
node_modules/make-dir/node_modules/semver/bin/semver.js
node_modules/node-addon-api/tools/conversion.js
node_modules/prebuild-install/bin.js
node_modules/mkdirp/bin/cmd.js
node_modules/color-support/bin.js
node_modules/rc/cli.js
node_modules/glob/dist/esm/bin.mjs
node_modules/@mapbox/node-pre-gyp/bin/node-pre-gyp
node_modules/which/bin/node-which
node_modules/nopt/bin/nopt.js
node_modules/semver/bin/semver.js
node_modules/sqlite3/node_modules/node-gyp/bin/node-gyp.js
node_modules/sqlite3/build-tmp-napi-v6/Makefile
node_modules/sqlite3/build-tmp-napi-v6/config.gypi

$ grep -lr /nix/store/1x276grqkqal97vbf7xrna218jr2kv84-nodejs-22.19.0-source 
node_modules/sqlite3/build-tmp-napi-v6/Makefile
node_modules/sqlite3/build-tmp-napi-v6/config.gypi

I'm looking into if it's possible to eliminate those. The AppImage ships those as well, but does seem to work fine without nodejs after all.

[fugidev]

I'm not really getting anywhere, and I can't really spare more time to sink into this at the moment. Best I can tell you so far is that nodejs (and patching the shebangs that reference it) is required for building keytar during dependency installation. It looks like element-desktop builds keytar using nix and symlinks it into node_modules. I could not easily get the same to work for joplin-desktop, but maybe that way it could be avoided to pull in nodejs.