expo-cli: init + implement overrideNodeAttrs

[jtojnar]

Motivation for this change

Closes: #93399

Had to implement overrideNodeAttrs to filter out optional @expo/traveling-fastlane-darwin dependency that was intentionally aborting the build on Linux.

Things done

• Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
• Built on platform(s)
  • NixOS
  • macOS
  • other Linux distributions
• Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
• Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
• Tested execution of all binary files (usually in ./result/bin/)
  • Successfully ran react-native app on Android using this
• Determined the impact on package closure size (by running nix path-info -S before and after)
• Ensured that relevant documentation is up to date
• Fits CONTRIBUTING.md.

[jtojnar]

cc @FRidh who implemented overridePythonAttrs I based this on

cc @Scriptkiddi who was also interested in this

[FRidh]

While I am not sure whether it is the correct direction to add these language/framework-specific overrides (see NixOS/rfcs#67 (comment)) I do think the implementation in #87394 would be preferred over us implementing our own ones every time.

[jtojnar]

Thanks, I was trying to find the PR but did not realize it was closed. I agree with you but in the meantime I would like a working, if only temporary solution.

What do you think about gating it on explicit acknowledgement that the function can be dropped at any time?

[FRidh]

Well, I say we should just use that PR. Having those override functions does not preclude having a common override function which I proposed (that could be say overrideArgs).

[jtojnar]

I think I will use the local internal function for now, rather than switching to a public API that would be deprecated after RFC 67. I will port to that once it gets accepted.