A more stable method of retrieving package information about npm2nix HOT 8 CLOSED

There's one other issue, the format of dependencies github:owner/name produces different directory layout in node_packages(owner/name instead of only name), i also have to handle this in nix.

from npm2nix.

Ouch, I wonder how this works for npm ls.

from npm2nix.

So I dug a little again, but isn't npm shrinkwrap what we want?

For instance:

cd popcorntime
npm install
npm shrinkwrap
cp npm-shrinkwrap.json nixpkgs/pkgs/applications/video/popcorntime/

Inside fetchnpm.nix:

stdenv.mkDerivation {
  builder = ''
    cp ${./npm-shrinkwrap.json} ./
    npm install
    cp -r node_modules $out
  '';
  outputHash = "...";
}

In default.nix link node_modules to the result of fetchnpm.
EDIT: I'm also wondering whether the result of installing shrinkwrapped dependencies will always result in the same node_modules (same hash). Do you know, or is this something to just try?
It's just an example, but is this a viable direction?

from npm2nix.

I did an experiment with npm-shrinkwrap. I ran npm shrinkwrap in popcorntime's repository and used the resulting file in a nix-expression where it runs npm install. There was some hackery, but it seems to be creating the same node_modules directory each time it is called here.

See here: https://gist.github.com/bobvanderlinden/05cb8e4b4400618ee487

from npm2nix.

The problem with shrinkwrap is that it uses the currently installed modules. If you run it against a fresh source without node_modules, it is empty.

Basically we need something that gets a package.json and dumps out the resolution. This resolution is the description nix needs to build the packages.

Then each of the packages in the resolution can be built, using the resolved dependencies. To get around the symlinked-dependencies-use-real-location-for-dependencies problem simply symlink one level down.

from npm2nix.

It might be a side-effect, but isn't the result of npm install && npm shrinkwrap the resolution you're looking for? It outputs a shrinkwrap file that contains the package names and versions of that time. Npm knows where to get those exact files. If that ran when you're packaging an application and include the shrinkwrap file in the nix package, it'll result in the exact same node_modules contents. A hash for the resulting node_modules directory will assert it is indeed always the same (it should be because that is what shrinkwrap is meant for).

Additionally, in an ideal situation the devs of an application itself include their version of the shrinkwrap file upon releasing stable versions. This can be reused, so that the package will include the exact packages the developers intended the application to use.

It's probably less space efficient and cost more time building than using npm2nix, but it might be more practical for maintaining some huge and complex packages.

from npm2nix.

may be it can be closed?

from npm2nix.

I haven't used npm2nix for quite a while, I'll close it. 👍

from npm2nix.