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.git
The 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-5
There are any number of reasons why a package might not build. Some of the most common ones are:
- The
nixfromnpm
tool wasn't able to generate the definition of one of the package's dependencies. It will insert in thebrokenPackage
function, which, as might be anticipated, never builds. Looking at the call tobrokenPackage
will 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
nixfromnpm
failed to resolve. E.g.foo@>=1.2.3-bar <2.3.4-baz.qux
. - Use
npm
to 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.
foo@1.2.3-xyz
. - Call
nixfromnpm
on that version. E.g.nixfromnpm -o /path/to/nix-node-packages -p 'foo%1.2.3-xyz'
. - Replace the call to
brokenPackage
withfoo_1-2-3-xyz
.
- See what version range
- The build fails with
npm
complaining about HTTP errors. This is usually caused by a dependency that wasn't satified, likely becausenixfromnpm
calculated 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
nix
view of things. In this case, you'll probably want tonix-shell
into the package and see what it's trying to do. Figure out how to stop it from doing these things, and supplyprePatch
orpostPatch
steps 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-packages
This 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-packages
This 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-packags
There 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.sh
Where path/to/nix-node-packages
is the path to this repo on your
system.