nodePackages.pnpm removed: "nodePackages has been removed because it was unmaintainable within nixpkgs" - migration guidance?

Help
1

Hi all,

I’m hitting this error when trying to enter my dev shell from a flake.nix on nixpkgs-unstable :slight_smile:

error: nodePackages has been removed because it was unmaintainable within nixpkgs

The offending line in my flake is nodePackages.pnpm inside a mkShell:

{
  inputs = {
    nixpkgs.url = "github:nixos/nixpkgs/nixpkgs-unstable";
  };
  outputs =
    { nixpkgs, ... }:
    let
      forAllSystems =
        function:
        nixpkgs.lib.genAttrs nixpkgs.lib.systems.flakeExposed (
          system: function nixpkgs.legacyPackages.${system}
        );
    in
    {
      formatter = forAllSystems (pkgs: pkgs.alejandra);
      devShells = forAllSystems (pkgs: {
        default = pkgs.mkShell {
          packages = with pkgs; [
            corepack
            bun
            nodejs_22
            nodePackages.pnpm
            postgresql
            git
            deno
          ];
        };
      });
    };
}

A couple of questions:

  1. Is replacing nodePackages.pnpm with the top-level pnpm the correct migration path?

  2. Is there a comprehensive list or tracking issue for which nodePackages.* attrs have been promoted to top-level vs. simply removed?

  3. For packages that were dropped entirely, is buildNpmPackage the recommended approach, or are there better alternatives?

  4. What was the reasoning behind removing the entire nodePackages set rather than deprecating individual broken packages? Should we be concerned about similar bulk removals in other package sets (e.g., pythonPackages, perlPackages)?
    I found this nixpkgs issue about repackaging with buildNpmPackage, but I couldn’t find clear migration docs. Any pointers would be appreciated.

Thanks!

1 Like
2

Is replacing nodePackages.pnpm with the top-level pnpm the correct migration path?

Yes that’s the correct one.

Is there a comprehensive list or tracking issue for which nodePackages.* attrs have been promoted to top-level vs. simply removed?

There is this project which tracks removed and repacked ones.

For packages that were dropped entirely, is buildNpmPackage the recommended approach, or are there better alternatives?

There are also some hooks which can be used more modular, but in most cases buildNpmPackage is okay to use.

What was the reasoning behind removing the entire nodePackages set rather than deprecating individual broken packages?

The way it was implemented in nixpkgs made it hard to maintain and led to regular merge conflicts between PR’s adding and updating different packages in nodePackages, also the packages in there were also more like applications and not like their own package system like pytonPackages, perlPackages and other language specific sets.

Should we be concerned about similar bulk removals in other package sets (e.g., pythonPackages, perlPackages)?

Mostly not as they are whole ecosystems and not just application that could also standalone in the top-level, they are also not falling in the same mistake that nodePackages made.

I found this nixpkgs issue about repackaging with buildNpmPackage, but I couldn’t find clear migration docs. Any pointers would be appreciated.

There is no real migration guide because node2nix and buildNpmPackage are so different that from how to use them that doing the packing from scratch would be easier than showing any specific migration for that.

2 Likes
3

What were those mistakes, if I may ask?

4

The main mistake was having one shared lock file between all packages in the package set, as this lead to having merge conflicts when at least 2 people wanted to add/remove/update a package in nodePackages.

6 Likes