Update node2nix with the upstream fixes to building bin links

[CMCDragonkai]

Specification

The new node2nix finally fixes the bin links problems: svanderburg/node2nix#302

It's time to check to see if this works for us and then remove our hack in default.nix

Additional context

• Emit lockfile v2 and fix bin links with NPM v7+ svanderburg/node2nix#302
• nodePackages: patch node2nix for npm v7+ and switch to building package set with current nodejs NixOS/nixpkgs#193337

Tasks

1. Update to the latest nixpkgs revision that contains this fix
2. Test if this works for TS demo lib
3. Merge and update all other repos

[CMCDragonkai]

It might be a good idea to create our own toolchain here and completely leave node2nix. The whole point of this would only be to build a "nix package" based on our project that generates TS code and has node modules.

It seems that if we were to generate the final executable, we would just put that into the Nix package, rather than leaving around node source code as the Nix package. That would make it far more similar to other Nix packages that just have the compiled executable left.

The only reason to package anything for Nix is the final application, not the NodeJS library, since Node libraries are not distributed in Nix, they are just source code, not shared objects.

Although Python libraries are distributed in Nix atm, and I've worked on that before. The reason that works is due to the way the final Python environment can easily load all the python packages directly from the PYTHON_PATH environment variable.

The equivalent NODE_PATH environment variable doesn't work as well.

Anyway, this means instead of trying to fit node2nix in, we could discard it entirely, and instead focus on building the final executable that would then work in Nix environment and distribute that.

The final executable must however be Nix's nodejs, and not just any nodejs, since that nodejs has to be bind to Nix C++ provided shared objects.

This also means pkg may not be the best tool either since it brings in nodejs interpreter from a separate external repo.

[CMCDragonkai]

This is going to be relevant to Polykey-CLI factoring out. MatrixAI/Polykey#268

[CMCDragonkai]

I believe we already have the latest node2nix. If I run node2nix I get 1.11.1. However it's actually hasn't been released so it's a bit confusing.

However we don't know if it works yet since a full complete build hasn't succeeded yet. I'll be moving this issue into Polykey-CLI since that will be the focus now.

[CMCDragonkai]

Ok so our default.nix still actually does the bin symlinking manually.

It's possible if we try to do a full build, it might break as we are still doing it.

We have to see if the new node2nix 1.11.1 (as per nixpkgs pin supplied in pkgs.nix) does the job already and in which case we can remove the # symlink bin executables section in our default.nix.

If it is no longer needed, then we can also remove jq from our derivation dependencies.

[CMCDragonkai]

I think node2nix is abandoned. The nixpkgs upstream isn't updating it.

And as per the above, the only reason we are using it is to create an "application", but we might as well just focus on creating the executable using pkg... or even before that, use esbuild output.

I think I'm going to get rid of node2nix.

To do this, I'll need to use default.nix to build this thing.

The problem is fetching all the dependencies.

Community https://discourse.nixos.org/t/future-of-npm-packages-in-nixpkgs/14285/25 says:

• dream2nix
• js2nix
• fetchNodeModule?

[CMCDragonkai]

https://discourse.nixos.org/t/announcing-js2nix-scale-your-node-js-project-builds-with-nix/23111/12 - so js2nix and buildNpmPackage.

Will try js2nix since this seems relevant to us.