Skip to content

Repackage node2nix generated packages using buildNpmPackage #229475

@ehllie

Description

@ehllie

Issue description

Currently a vast majority of NPM packages available in Nixpkgs are generates using node2nix. It generates a nix expression form the node-packages.json file. However it's very hard to maintain. Any time a new package is added to that list or updated, node2nix has to update every single package listed in node-packages.json using a code-gen script. That forces PRs that touch that part of the ecosystem to rerun the code-gen script each time only other PR is merged. This is further exacerbated by the time the script takes to run. As of writing this post, there are 408 packages in node-packages.json, and it takes ~4h to run the generation script.

Proposed solution

Nowadays an alternative tool, buildNpmPackage, is available, but plenty of the packages already listed there were added there before its creation. Not all of the packages can be build using the new tool, but I think it would be worthwhile to review how many of them could be repackaged that way. That should at the very least make the time of running the code-gen script shorter.

As such, I've listed all the packages that are build using node2nix. My intention is this issue could be used to collaborate on the repackaging efforts. If any package gets successfully repackaged, or determined to not be possible to be built using builtNpmPackage, I'd appreciate having that mentioned here so that I can update the list and move that package to an appropriate location.

List moved to Repackage node2nix packages.

Want to contribute? Here's a general walkthrough of how you can do that

  • Find a package that's not listed as repacked in this post (and better yet search for it in nixpkgs, I try to update this post somewhat frequently but I'm not infallible)
  • Check what tool it's using upstream. npm/ pnpm/ yarn? does it keep it's lock file checked out in vcs? If it's using both npm and has a checked out package-lock.json it might be a good candidate
  • Given the happy scenario try to make a callPackage derivation using buildNpmPackage and put it somewhere appropriate in the nixpkgs package tree.
  • Remove the old package from node-packages.json and add it to aliases.nix

In case the package does not follow the happy scenario you can mention it here so I can move it to the appropriate group of packages. For an example of a package repackaged this way you can check #229512

I've discussed this idea with @SuperSandro2000 in another PR briefly, but I'd appreciate other people responsible for maintaining the node ecosystem to weigh in as well. @NixOS/node would this be the right way to go about this? Where should the repackaged packages be put? Is doing this worthwhile?

Sub-issues

Metadata

Metadata

Assignees

No one assigned

    Labels

    3.skill: sprintableA larger issue which is split into distinct actionable tasks5.scope: trackingLong-lived issue tracking long-term fixes or multiple sub-problems6.topic: nodejsNode.js is a free, open-source, cross-platform JavaScript runtime environment

    Projects

    Status

    Tracking Issue

    Status

    In progress

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions