[24.05 backport] nodejs changes

[aduh95]

Description of changes

Generated with

for commit in $(git log HEAD...origin/staging --reverse --pretty=format:"%H" -- pkgs/development/web/nodejs/); do
             echo "About to cherry-pick $commit";
             git cherry-pick -x "$commit";
             read -p "Press any key to resume ...";
done

I only picked the commits that did not break the builds.

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.

[tie]

Hm, did the commit that switches the build system to ninja fail for some reason?
(note that we’d also need #337360 as a followup fix)

[Ma27]

note that we’d also need #337360 as a followup fix

Given the significant changes to the build-system and the fact that there is in fact fall-out already, I'd like to raise the question whether it's actually a good idea to backport all of that.

Would it be an option to just backport the bumps and bugfixes (if any?)

[aduh95]

I agree with Maximilian, not backporting that ninja change minimizes the risk of breakage. I don't remember exactly if I dropped it because of a build failure, I think I didn't even try to resolve the conflicts and just skipped it. FWIW I'm not against backporting it ever, but I'd rather not be the one doing it.

Would it be an option to just backport the bumps and bugfixes (if any?)

Unless I'm missing something, that's currently the case. The changes are either version bump, bug fixes, or "ineffective" changes included just to minimize the amount of conflicts (i.e. all test-related changes don't have any impact on the 24.05 branches because we don't run the tests there, see 21e3782).

[Ma27]

FWIW I'm not against backporting it ever, but I'd rather not be the one doing it.

I don't think this needs to be backported at all: yes, further version bumps and all of that will be more painful, but I'd argue it's less of a risk than backporting all the build-system changes. Also, the situation will resolve itself by the end of the year when 24.05 gets retired.

Unless I'm missing something, that's currently the case

I thought this wasn't the case before since the build-system changes were included? But on a second glance, this isn't the case anymore (I guess the NINJA env change was a red herring and I fell for it 🙈 ).

In that case it's fine I'd say.

[tie]

I guess the NINJA env change was a red herring and I fell for it

Yes, I was a bit confused by this as well and was half-expecting other ninja-related changes 😅

Would it be an option to just backport the bumps and bugfixes (if any?)

Perhaps we shouldn’t backport 4b90b5e since it is a non-trivial change to the Node.js build process (i.e. using an emulator instead of building for multiple platforms)? Otherwise the commits in this PR look good to me.

[aduh95]

Marking as draft until #339252 can be included (because of #336556 (comment)), and 4b90b5e is removed from this PR.

[aduh95]

7f3e4cc not found in any pickable branch

I guess I should wait for staging-next to be merged into staging. EDIT: that's done, the cherry-pick workflow no longer reports it as unpickable.