I've updated this PR now to the new version of linkwarden which does not need patching any more (all my PRs have been merged)

Just updated my own linkwarden instance and everything works as expected

Updated to version 2.11.5

Tested the module, it seams to work OK (thanks for the amazing work ❤️ )
However I have troubles when first setting up the service:

• I do not have registration enabled, as I don't want anyone on the internet to create accounts on my server
• But no base account are generated during initialisation.

One quick fix would be to enable temporarily the registration, and disable it later on.
Would there be a nix way to declaratively ensure users exist, with a specific passwordFile ?

EDIT:
In the service initialisation, if we launch Linkwarden with registration enabled, and iterate through the map of users to create, we can talk with the API endpoint to ensure they exist, and create them if they don't.
I don't really like this hack as I think it would be better done upstream, but should work enough

Yes, something like that should be done upstream, not in this module. One other workaround is to just use OIDC instead of the builtin user management (that's what I use)

I just retested the module on my machine. In my setup, secrets are stored in sops-nix, and I use Authelia for OIDC. The module seems to be working perfectly!

services.linkwarden = {
  enable = true;

  environment = {
    NEXT_PUBLIC_AUTHELIA_ENABLED = "true";
    NEXTAUTH_URL = "https://linkwarden.${publicDomain}/api/v1/auth";
    AUTHELIA_WELLKNOWN_URL = "https://authelia.${publicDomain}/.well-known/openid-configuration";
    AUTHELIA_CLIENT_ID = oidc_clients.linkwarden.client_id;
    AUTHELIA_CLIENT_SECRET = oidc_clients.linkwarden.secret_password;
  };

  secretFiles = {
    POSTGRES_PASSWORD = config.sops.secrets."linkwarden/postgres_password".path;
    NEXTAUTH_SECRET = config.sops.secrets."linkwarden/nextauth_secret".path;
  };
};

@drupol I have addressed all review comments

Something seems to be wrong with ofborg, I can build and run the PR just fine.
Yeah, the error looks unrelated:

       error: cannot open connection to remote store 'daemon': error: reading from file: Connection reset by peer

nixpkgs-review result

Generated using nixpkgs-review.

Command: nixpkgs-review pr 347353
Commit: e95e49ce7ef4b0ab9018554cf272e4990eeb7bde

x86_64-linux

./pages/api/documents/[id]/send.ts:45:29
Type error: Parameter 'recipient' implicitly has an 'any' type.
43 |

44 |   let sentRequests = 0;

45 |   recipients.forEach(async (recipient) => {

|                             ^

46 |     await sendSigningRequest(recipient, document, user).catch((err) => {

47 |       console.log(err);

48 |       return res.status(502).end("Coud not send request for signing.");

info  - Linting and checking validity of types ...

ERROR: npm build failed

Here are a few things you can try, depending on the error:

Make sure your build script (build) exists

If there is none, set dontNpmBuild = true.
If the error being thrown is something similar to "error:0308010C:digital envelope routines::unsupported", add NODE_OPTIONS = "--openssl-legacy-provider" to your derivation

See nodejs 17: digital envelope routines::unsupported webpack/webpack#14532 for more information.

I added one now. I was not sure as the 25.11 release notes file did not have the "New modules" sections so I thought the release notes might no longer show new modules

Ok, that just fails. Where am I supposed to add to the release notes? The "other notable changes section"?

It's here: https://github.com/NixOS/nixpkgs/blob/master/nixos/doc/manual/release-notes/rl-2511.section.md

oh weird, why are those (partially) duplicated?

I'm not sure why but I guess the final page is generated from partials. Thanks for the work, I'm running the module for a few months without any issue 👍