On 17-04-25 12:21pm, Sander van der Burg wrote: > I'm not sure if you have read my blog articles correctly, but what node2nix > currently does is one derivation per application and statically bundles all > NPM dependencies with it. The old approach that npm2nix used to implement > was a derivation per dependency and symlinking between them. As explained > in this blog post: > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html > this works for many packages, but does not reliably work in all cases. > Moreover, it does not work with packages having cyclic dependencies.
Apart from cyclic dependencies and leaving out “flattened” trees, are there any other deal-breakers you can think of? > Now yarn (and other approaches such as ied) do obviously a much better job > than NPM in some aspects. Unfortunately, as of today, NPM remains the > de-facto standard for Node.js package deployment, and I'm not sure if this > will ever change. yarn is pretty much a drop-in replacement for npm. Instead of `npm install && node2nix` you say `yarn install && yarn2nix` and you get a local `node_modules` and in yarn’s case also a `yarn.lock`. So as far as packaging goes, adoption should not matter imho. > The latter aspect can only be solved if NPM makes their dependency > addressing and composition facilities better. +1 -- Proudly written in Mutt with Vim on NixOS. Q: Why is this email five sentences or less? A: http://five.sentenc.es May take up to five days to read your message. If it’s urgent, call me. _______________________________________________ nix-dev mailing list [email protected] https://mailman.science.uu.nl/mailman/listinfo/nix-dev
