[Nix-dev] yet another npm2nix reengineering attempt

[zimbatm]

As long as it's more reliable than what we have right now I'm all for it.
First we need reliable, then optimize closure size.


On Tue, 1 Mar 2016 at 14:42 Sander van der Burg <svanderburg at gmail.com>
wrote:

> Haha :)
>
> Well, I have been thinking about keeping the packages and all their
> dependencies in their own store directories as well, but I eventually came
> to the conclusion that it is impossible if you want to support the
> inclusion of dependencies residing in any of the parent node_modules/
> folders. :)
>
> Although it would be possible to create store paths for each of the
> packages involved (with their expected dependencies in their node_modules/
> folder, leaving the ones that have been resolved by the includers out),
> there is yet another problem -- the CommonJS module system dereferences
> symlinks and looks relative from there. So that means that any package
> resolves to a path in the Nix store first and then CommonJS looks in parent
> directories from there. As you may know, the parent of the a Nix store path
> is /nix/store, which makes it impossible for the CommonJS module system to
> find any parent modules. :)
>
> Second, we can't avoid omitting resolved parent dependencies, because we
> also have to deal with crazy packages that have cyclic dependencies. The
> reason that NPM "knows" how to handle them is because it omits dependencies
> that have been encountered a second time. :)
>
> So as you may see: it is all quite annoying and painful. :(
>
> Maybe my solution is not the best/elegant, but it at least handles it.
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160301/1596c173/attachment.html