nodejs_22: 22.4.1 -> 22.5.1

[aduh95]

Description of changes

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/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (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.

---

Add a 👍 reaction to pull requests you find important.

[vcunat]

Why staging? As this version isn't the default one, the rebuild amount won't be high (for Hydra.nixos.org at least, by ofBorg as well).

[tie]

Why staging?

I can’t speak for this particular PR, but I’d target staging for Node.js because changes usually cause mass rebuilds and we’ve seen some inconsistent master ↔ staging merges before (e.g. #325844 (comment)).

For example, if we run nixfmt on Node.js package with some minor manual cleanup on top of that, by this policy these changes should target master branch since there would be zero rebuilds. If, at the same time, staging branch contains other changes (e.g. another unrelated or possibly overlapping refactor), merging would require human intervention.

That is, since most of the Node.js package development happens on staging branch, I think targeting it for all changes reduces the likelihood of regressions and conflicts for staging merges. Changes take a bit longer to reach unstable release channel, but otherwise I’m not aware of any other issues with this approach.

[aduh95]

To add to what @tie said, if I have to add some changes that will impact the other Node.js versions (e.g. in this very PR, if the change suggested in #327967 (comment) lands upstream, it would have impact on all three versions of Node.js who are currently using use-correct-env-in-tests.patch), it's more convenient to not have to do the dance to change the base branch.

[tie]

👍