Merge master into staging-nixos

It's better to try to use a Nix tool that understands the lock file.

Using a different tool might give you a hard-to-understand error because different packages have been installed.

An example of problems that could arise can be found [here](https://github.com/NixOS/nixpkgs/pull/126629).

Upstream use npm, but this is an attempt to package it with `yarn2nix` (that uses yarn.lock).

Using a different tool forces you to commit a lock file to the repository.

These files are fairly large, so when packaging for nixpkgs, this approach does not scale well.

Exceptions to this rule are:

- When you encounter one of the bugs from a Nix tool. In each of the tool-specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to re-create a lock file and commit it to Nixpkgs. In general `yarn2nix` has fewer known problems, and so a simple search in Nixpkgs will reveal many `yarn.lock` files committed.

- When you encounter one of the bugs from a Nix tool. In each of the tool-specific instructions, known problems will be detailed. If you have a problem with a particular tool, then it's best to try another tool, even if this means you will have to re-create a lock file and commit it to Nixpkgs.

- Some lock files contain particular version of a package that has been pulled off npm for some reason. In that case, you can recreate upstream lock (by removing the original and `npm install`, `yarn`, ...) and commit this to nixpkgs.

- The only tool that supports workspaces (a feature of npm that helps manage sub-directories with different package.json from a single top level package.json) is `yarn2nix`. If upstream has workspaces you should try `yarn2nix`.

### Try to use upstream package.json {#javascript-upstream-package-json}

Each tool has an abstraction to just build the node_modules (dependencies) directory.

You can always use the `stdenv.mkDerivation` with the node_modules to build the package (symlink the node_modules directory and then use the package build command).

The node_modules abstraction can be also used to build some web framework frontends.

For an example of this see how [plausible](https://github.com/NixOS/nixpkgs/blob/master/pkgs/servers/web-apps/plausible/default.nix) is built. `mkYarnModules` to make the derivation containing node_modules.

Then when building the frontend you can just symlink the node_modules directory.

## Tool-specific instructions {#javascript-tool-specific}

- `yarnKeepDevDeps`: Disables the removal of devDependencies from `node_modules` before installation.

#### yarn2nix {#javascript-yarn2nix}

> [!WARNING]

> The `yarn2nix` functions have been deprecated in favor of `yarnConfigHook`, `yarnBuildHook` and `yarnInstallHook` (for Yarn v1) and `yarn-berry_*.*` tooling (Yarn v3 and v4). Documentation for `yarn2nix` functions still appears here for the sake of the packages that still use them. See also a tracking issue [#324246](https://github.com/NixOS/nixpkgs/issues/324246).

##### Preparation {#javascript-yarn2nix-preparation}

You will need at least a `yarn.lock` file. If upstream does not have one you need to generate it and reference it in your package definition.

If the downloaded files contain the `package.json` and `yarn.lock` files they can be used like this:

```nix

{

  offlineCache = fetchYarnDeps {

    yarnLock = src + "/yarn.lock";

    hash = "....";

  };

}

```

##### mkYarnPackage {#javascript-yarn2nix-mkYarnPackage}

> [!WARNING]

> The `mkYarnPackage` functions have been deprecated in favor of `yarnConfigHook`, `yarnBuildHook` and `yarnInstallHook` (for Yarn v1) and `yarn-berry_*.*` tooling (Yarn v3 and v4). Documentation for `mkYarnPackage` functions still appears here for the sake of the packages that still use them. See also a tracking issue [#324246](https://github.com/NixOS/nixpkgs/issues/324246).

`mkYarnPackage` will by default try to generate a binary. For packages only generating static assets (Svelte, Vue, React, Webpack, ...), you will need to explicitly override the build step with your instructions.

It's important to use the `--offline` flag. For example if you script is `"build": "something"` in `package.json` use:

```nix

{

  nativeBuildInputs = [ writableTmpDirAsHomeHook ];

  buildPhase = ''

    runHook preBuild

    yarn --offline build

    runHook postBuild

  '';

}

```

The `distPhase` is packing the package's dependencies in a tarball using `yarn pack`. You can disable it using:

```nix

{ doDist = false; }

```

The configure phase can sometimes fail because it makes many assumptions that may not always apply. One common override is:

```nix

{

  configurePhase = ''

    runHook preConfigure

    ln -s $node_modules node_modules

    runHook postConfigure

  '';

}

```

or if you need a writeable node_modules directory:

```nix

{

  configurePhase = ''

    runHook preConfigure

    cp -r $node_modules node_modules

    chmod +w node_modules

    runHook postConfigure

  '';

}

```

##### mkYarnModules {#javascript-yarn2nix-mkYarnModules}

This will generate a derivation including the `node_modules` directory.

If you have to build a derivation for an integrated web framework (Rails, Phoenix, etc.), this is probably the easiest way.

#### Overriding dependency behavior {#javascript-mkYarnPackage-overriding-dependencies}

In the `mkYarnPackage` record the property `pkgConfig` can be used to override packages when you encounter problems building.

For instance, say your package is throwing errors when trying to invoke node-sass:

```

ENOENT: no such file or directory, scandir '/build/source/node_modules/node-sass/vendor'

```

To fix this we will specify different versions of build inputs to use, as well as some post install steps to get the software built the way we want:

```nix

mkYarnPackage rec {

  pkgConfig = {

    node-sass = {

      buildInputs = with final; [

        python

        libsass

        pkg-config

      ];

      postInstall = ''

        LIBSASS_EXT=auto yarn --offline run build

        rm build/config.gypi

      '';

    };

  };

}

```

##### Pitfalls {#javascript-yarn2nix-pitfalls}

- If version is missing from upstream package.json, yarn will silently install nothing. In that case, you will need to override package.json as shown in the [package.json section](#javascript-upstream-package-json)

- Having trouble with `node-gyp`? Try adding these lines to the `yarnPreBuild` steps:

  ```nix

  {

    yarnPreBuild = ''

      mkdir -p $HOME/.node-gyp/${nodejs.version}

      echo 9 > $HOME/.node-gyp/${nodejs.version}/installVersion

      ln -sfv ${nodejs}/include $HOME/.node-gyp/${nodejs.version}

      export npm_config_nodedir=${nodejs}

    '';

  }

  ```

  - The `echo 9` steps comes from this answer: <https://stackoverflow.com/a/49139496>

  - Exporting the headers in `npm_config_nodedir` comes from this issue: <https://github.com/nodejs/node-gyp/issues/1191#issuecomment-301243919>

- `offlineCache` (described [above](#javascript-yarn2nix-preparation)) must be specified to avoid [Import From Derivation](#ssec-import-from-derivation) (IFD) when used inside Nixpkgs.

#### Yarn Berry v3/v4 {#javascript-yarn-v3-v4}

Yarn Berry (v3 / v4) have similar formats, they start with blocks like these:

    "index.html#overriding-the-generator",

    "index.html#javascript-node2nix",

    "index.html#javascript-node2nix-preparation",

    "index.html#javascript-node2nix-pitfalls"

    "index.html#javascript-node2nix-pitfalls",

    "index.html#javascript-yarn2nix-mkYarnPackage",

    "index.html#javascript-yarn2nix",

    "index.html#javascript-yarn2nix-preparation",

    "index.html#javascript-yarn2nix-mkYarnModules",

    "index.html#javascript-mkYarnPackage-overriding-dependencies",

    "index.html#javascript-yarn2nix-pitfalls"

  ],

  "sec-nixpkgs-release-26.05-lib": [

    "release-notes.html#sec-nixpkgs-release-26.05-lib"

  "javascript-yarninstallhook": [

    "index.html#javascript-yarninstallhook"

  ],

  "javascript-yarn2nix": [

    "index.html#javascript-yarn2nix"

  ],

  "javascript-yarn2nix-preparation": [

    "index.html#javascript-yarn2nix-preparation"

  ],

  "javascript-yarn2nix-mkYarnPackage": [

    "index.html#javascript-yarn2nix-mkYarnPackage"

  ],

  "javascript-yarn2nix-mkYarnModules": [

    "index.html#javascript-yarn2nix-mkYarnModules"

  ],

  "javascript-mkYarnPackage-overriding-dependencies": [

    "index.html#javascript-mkYarnPackage-overriding-dependencies"

  ],

  "javascript-yarn2nix-pitfalls": [

    "index.html#javascript-yarn2nix-pitfalls"

  ],

  "javascript-yarnBerry-missing-hashes": [

    "index.html#javascript-yarnBerry-missing-hashes"

  ],

  adding `pkg-config`, `xfce4-dev-tools`, and `wrapGAppsHook3` to your `nativeBuildInputs` and

  `--enable-maintainer-mode` to your `configureFlags`.

- `yarn2nix`/`yarn2nix-moretea` and its tooling(`mkYarnPackage`, `mkYarnModules`, and `fixup_yarn_lock`) have been removed as they were unmaintainable in nixpkgs. If you want to build with Yarn V1 going forward, use the hooks instead(`yarnBuildHook`, `yarnConfigHook`, and `yarnInstallHook`). See the yarn v1 documentation in the nixpkgs manual for more details.

- `albert` has been updated to the version 34.0.5. This release redesigns the query system to support stateful asynchronous handlers and infinite scrolling, and adds internationalized tokenization.

  This update introduces several breaking changes: the Python plugin interface is now v5.0, the `PATH` plugin has been renamed to `Commandline`, and the QStylesheets-based widgets box model frontend has been removed.

  For more information read the [changelog for 34.0.0](https://albertlauncher.github.io/2026/01/19/albert-v34.0.0-released/).

- The `libcxxhardeningextensive` hardening flag has been **disabled** by default. Enabling it by default in 25.11 was unintentional and may have had a negative effect on performance in some cases. `libcxxhardeningfast` remains enabled by default.

- The packages `ibtool`, `actool` and `re-plistbuddy` have been added, providing reimplementations of the corresponding proprietary Apple tools. They are more compatible with the originals than the previously existing `xcbuild` package, and should enable more darwin software to be built from source.

- Switch inhibitors were introduced, which add a pre-switch check that compares a list of strings between the previous and the new generation, and refuses to switch into the new generation when there is a difference between the two lists. This allows to avoid switching into a system when for instance the systemd version changed by adding `config.systemd.package.version` to the switch inhibitors for your system. You can still forcefully switch into any generation by setting `NIXOS_NO_CHECK=1`.

- GNU Taler has been updated to version 1.3.

            description = ''

              Addresses (IPv4 or IPv6) to listen on for connections by the reverse proxy/tls terminator.

              If set to `null`, tuwunel will listen on IPv4 and IPv6 localhost.

              Must be `null` if `unix_socket_path` is set.

            '';

          };

          global.port = lib.mkOption {

  config = lib.mkIf cfg.enable {

    assertions = [

      {

        assertion = !(cfg.settings ? global.unix_socket_path) || !(cfg.settings ? global.address);

        message = ''

          In `services.matrix-tuwunel.settings.global`, `unix_socket_path` and `address` cannot be set at the

          same time.

          Leave one of the two options unset or explicitly set them to `null`.

        '';

      }

      {

        assertion = cfg.user != defaultUser -> config ? users.users.${cfg.user};

        message = "If `services.matrix-tuwunel.user` is changed, the configured user must already exist.";

      requires = [

        "network-online.target"

      ]

      ++ lib.optionals cfg.database.createLocally [ "postgresql.service" ];

      ++ lib.optionals cfg.database.createLocally [ "postgresql.target" ];

      after = [

        "network-online.target"

      ]

      ++ lib.optionals cfg.database.createLocally [ "postgresql.service" ];

      ++ lib.optionals cfg.database.createLocally [ "postgresql.target" ];

      wantedBy = [ "multi-user.target" ];

      environment = cfg.environment // {

        # Required, otherwise chrome dumps core

        "network-online.target"

        "linkwarden.service"

      ]

      ++ lib.optionals cfg.database.createLocally [ "postgresql.service" ];

      ++ lib.optionals cfg.database.createLocally [ "postgresql.target" ];

      after = [

        "network-online.target"

        "linkwarden.service"

      ]

      ++ lib.optionals cfg.database.createLocally [ "postgresql.service" ];

      ++ lib.optionals cfg.database.createLocally [ "postgresql.target" ];

      wantedBy = [ "multi-user.target" ];

      environment = cfg.environment // {

        # Required, otherwise chrome dumps core