Skip to content

Latest commit

 

History

History
138 lines (110 loc) · 5.37 KB

README.md

File metadata and controls

138 lines (110 loc) · 5.37 KB
Raw

Nix node package repository

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.

Using this library

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

If a package doesn't build

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 the brokenPackage function, which, as might be anticipated, never builds. Looking at the call to brokenPackage will tell you why it couldn't build it. In my experience, this is because nixfromnpm's version range checker is not completely up to spec, and it's unable to find a version that satisfies the bounds given by a package.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. [email protected].
    • 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 with foo_1-2-3-xyz.
  • The build fails with npm complaining about HTTP errors. This is usually caused by a dependency that wasn't satified, likely because nixfromnpm 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 to nix-shell into the package and see what it's trying to do. Figure out how to stop it from doing these things, and supply prePatch or postPatch 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.

Extending the libraries

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.

Adding new packages to the central package set

$ 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.

Create a new package set which refers to the central set

$ 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.

Generate a default.nix file from a project

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

Test-building all libraries

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.