firebase-tools: enable building on node 22

[sarahec]

1. Pulls in an upstream patch to replace the four-year old ajv JSON validator with a modern version. It was triggering compilation problems when built in the sandbox.
2. Adds a local patch to override nan -- the node native interfaces -- to a version supporting node 22 (and earlier).

Fixes #369813

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/)
• 25.05 Release Notes (or backporting 24.11 and 25.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.

[TomaSajt]

Btw, why is that override used? I just copied the diff after running npm update nan and it didn't add the override part, but still seemed to work.

[sarahec]

Btw, why is that override used? I just copied the diff after running npm update nan

You mentioned earlier that updating nan affected this in the lockfile and you were able to build using that. But firebase-tools doesn't supply a lockfile, just the shrinkwrap file. buildNodePackage runs checks before and after loading the package.json to make sure the packages file and shrinkwrap match with the source version. So I can't call npm update nan in the build step as it will break these checks.

Also, nix builds need to be deterministic -- by specifying the override in package.json, we get a repeatable build (as opposed to an update which will change over time).

[TomaSajt]

Yes, of course, and also npm update nan would need network anyways.
I'm just wondering how you generated your patch file: I generated mine by doing npm update nan in the repo and then running git diff.

Also, is shrinkwrap not the same as package-lock?

[TomaSajt]

LGTM
these will go away anyways once upstream gets a new version

[sarahec]

Yes, of course, and also npm update nan would need network anyways. I'm just wondering how you generated your patch file: I generated mine by doing npm update nan in the repo and then running git diff.

I added the override in a fork of firebase-tools then ran npm run build. That emitted package.lock and a revised npm-shrinkwrap

Also, is shrinkwrap not the same as package-lock?

shrinkwrap is a superset of package.lock and can be copied/renamed to form a package lock. I had to apply the override in the package.json to get the correct values in the output lockfiles.

EDIT: See later comments. My reasoning wasn't quite correct.

[sarahec]

Mirroring the override vs npm update question at firebase/firebase-tools#8097

[sarahec]

I ran an experiment: what would happen if I tried to regenerate the shrinkwrap file? It turns out that doens't work -- there are multiple compilation errors. So a npm update nan against the shrinkwrap would work.

Would you prefer that I remove the override from the patch? (We'll see which direction the upstream wants to do also.)

[TomaSajt]

LGTM
we can decide on the upstream PR whether it should be an override or not

[TomaSajt]

I'll merge in 15 minutes. I don't think we should wait for too long, since fixing a broken build is always a net positive.

[sarahec]

@TomaSajt thank you for being patient with me

[TomaSajt]

@TomaSajt thank you for being patient with me

I was also discovering and experimenting with stuff in real time while discussing this, so we all gained some useful experience.

Sidenote, I still have #369163 where I first encountered the nodejs_22 incompatibility