Hmm, 5 MB derivation, that's one hell of a package!

Building a derivation per dependency and symlinking node_modules/ folders? this is how npm2nix was built. However, I was forced to deviate from that convention for compatibility reasons (this also explains why node2nix was born, and nobody continued npm2nix):

The reasons why I have implemented a derivation per dependency closure strategy, rather than derivation per package/dependencies are as follows:

When deploying a dependency or transitive dependency, NPM scans for parent dependencies (in parent node_modules/ folders) for packages that satisfy a dependency specifier. This also (sometimes) means that, when a version range is specified, the version that ends up being used is not the latest. This is a weird oddity, but a requirement to be compatible.
We also need to break cyclic dependencies somehow. Again, the above strategy is the answer -- when a parent package already provides a dependency, it will not be included again. This is also a problem npm2nix cannot cope with
Third reason is that NPM "flattens" the dependency tree by moving non-conflicting dependencies as high in the node_modules/ tree as possible. This is an imperative operation.
Another reason why symlinks don't work is because is because of relative module paths -- NPM resolves symlinks, and as a result: relative dependencies cannot be found, because the base directory resolves to /nix/store.

I am already thinking for a while on implementing a better strategy. At the moment, the node-env.nix was already complicated, and it has involved into a bigger and more complex beast.

The best option we have is to rework node-env.nix to use the builtins.genericClosure function.

Reduce the derivation size #46

Description

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions