This is a collection of node packages expressed in the nix
language. They can be installed via the nix package manager. They have
been generated by
nixfromnpm. The packages
defined in this repo can be used as-is, for example as buildInputs
or propagatedBuildInputs to other nix derivations, or can be used
with nixfromnpm to auto-generate more nix expressions for other node
packages.
First I assume you have nix installed, or else why would you be using this? ;)
Clone the repo:
$ git clone https://github.com/adnelson/nix-node-packages.gitThe expressions here refer to a nixpkgs path variable, so make sure
you have it your NIX_PATH. For example, to point it at your
nixpkgs channel:
$ export NIX_PATH="$HOME/.nix-defexpr/channels:$NIX_PATH"After that you're free to do whatever you please with the
library. Packages are located under the top-level attribute
nodePackages. An unqualified name will build the latest version (as
determined by comparing package version names), while a particular
version can be referred to as shown below. For example, the following
commands build the latest version of grunt, and version 0.4.5,
respectively:
$ nix-build nix-node-packages/nodePackages -A nodePackages.grunt
$ nix-build nix-node-packages/nodePackages -A nodePackages.grunt_0-4-5There are any number of reasons why a package might not build. Some of the most common ones are:
- The nixfromnpmtool wasn't able to generate the definition of one of the package's dependencies. It will insert in thebrokenPackagefunction, which, as might be anticipated, never builds. Looking at the call tobrokenPackagewill tell you why it couldn't build it. In my experience, this is becausenixfromnpm's version range checker is not completely up to spec, and it's unable to find a version that satisfies the bounds given by apackage.json. If this is the case, the easiest way to fix it is to:- See what version range nixfromnpmfailed to resolve. E.g.foo@>=1.2.3-bar <2.3.4-baz.qux.
- Use npmto manually build the package at the given version bounds. E g.npm install foo@>=1.2.3-bar <2.3.4-baz.qux.
- See what version it ends up building. E.g. [email protected].
- Call nixfromnpmon that version. E.g.nixfromnpm -o /path/to/nix-node-packages -p 'foo%1.2.3-xyz'.
- Replace the call to brokenPackagewithfoo_1-2-3-xyz.
 
- See what version range 
- The build fails with npmcomplaining about HTTP errors. This is usually caused by a dependency that wasn't satified, likely becausenixfromnpmcalculated the wrong dependency. In this case, use steps similar to the above to find out what the actual dependency should be, and modify the package definition to include the correct one.
- A package build script is attempting to do some hacky bullshit like
modifying its dependencies. This, of course, is not kosher in the
nixview of things. In this case, you'll probably want tonix-shellinto the package and see what it's trying to do. Figure out how to stop it from doing these things, and supplyprePatchorpostPatchsteps to apply those changes.
Fixing broken packages can be a pain, but because the way nix works, you'll only need to fix them once (although, getting that to propagate to future versions might not be as easy). If you fix a package here, please feel free to make a pull request so that others can benefit.
It's possible that you'll want to add additional packages that haven't
been defined here. Alternatively, you might have your own packages,
perhaps private, that you want to generate expressions for, but not
have alongside all of the other packages in this repo. While you can
always write these packages by hand, it's easier to do this with
nixfromnpm. It can be obtained
here. As with fixes above,
feel free to pull request any new packages added, whether by hand or
auto-generated.
$ nixfromnpm -p package1 -p package2 -o nix-node-packagesThis will calculate expressions for package1 and package2, and
place the generated expressions alongside all of the existing
packages.
$ nixfromnpm -p package1 -p package2 -o path/to/new/set --extend nix-node-packagesThis will calculate expressions for package1 and package2, and
place them and their dependencies in path/to/new/set. However, any
dependencies which exist in nix-node-packages/nodePackages will not
need to be fetched, and will not appear in path/to/new/set.
You might have a project which has a package.json that specifies a
bunch of dependencies. You can use nixfromnpm to generate
expressions for the package's dependencies, and output a default.nix
file for the package.
$ nixfromnpm -f path/to/project -o nix-node-packagsThere is a script sibling to this readme which can be executed which will build all of the node packages defined here, except ones which are marked as broken. To run it:
$ path/to/nix-node-packages/test_build_all.shWhere path/to/nix-node-packages is the path to this repo on your
system.