Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/adnelson/nix-node-packages

A bunch of NPM packages defined in the nix language.
https://github.com/adnelson/nix-node-packages

Last synced: 16 days ago
JSON representation

A bunch of NPM packages defined in the nix language.

Awesome Lists containing this project

README 

        
# 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](https://github.com/adnelson/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:



```bash

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



```bash

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



```bash

$ 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](https://github.com/adnelson/nixfromnpm). 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



```bash

$ 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



```bash

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



```bash

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



```bash

$ path/to/nix-node-packages/test_build_all.sh

```



Where `path/to/nix-node-packages` is the path to this repo on your

system.