Hmm, OK. I still don't see why each package shouldn't live in its own store dir (perhaps without dependencies linked in), but whatever, I don't use node anymore :D
On 2016-03-01 09:12, Sander van der Burg wrote: > It's stateful because the packages that end up in a dependency's node_modules/ folder depend on the packages that have been stored in any of the includer's (parent directory's) node_modules/ folders. When a dependency has been encountered a second time (that fits within a package's version range), NPM will not include it again. > > For example: if a package would declare a dependency (such as: "optparse": ">= 1.0.3") and any of the parent node_modules/ folders would provide version 1.0.5, then optparse/ will not be deployed again in the package's private node_modules/ folder. Instead, it will be left out and the package binds to the version of the parent. > > Second, with npm 3.x's flat module installations, we must move packages as high as possible in the nested node_modules/ hierarchy, until a conflict has been encountered. > > On Tue, Mar 1, 2016 at 1:53 PM, Shea Levy <[email protected]> wrote: > >> "including NPM dependencies is stateful" how so? Having separate >> derivations symlinked in would give you sharing, no? >> >> On 2016-03-01 08:15, Sander van der Burg wrote: >> > Hi, >> > >> > I don't know how many of you have noticed my latest blog post >> > >> > (http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html [1] >>> [1]), but I did yet another reengineering attempt for npm2nix. Its >>> main objective is to also support npm 3.x's flat module installations >> > (npm 3.x comes with Node.js 5.x). >> > >> > In the second reengineered version, I compute the entire dependency >> > graph ahead of time and build the entire set of dependencies in one >> > derivation -- there is no good reason to make them individual Nix >> > packages, because including NPM dependencies is stateful. >> > >> > The new reengineered version supports both Node.js 4.x and 5.x. By >> > default, it generates expressions for 4.x (I made this the default, >> > since 4.x is the LTS release): >> > >> > $ npm2nix >> > >> > Adding the -5 parameter causes it to generate expressions for Node.js >> > 5.x: >> > >> > $ npm2nix -5 >> > >> > The code lives in the same repository as the old reengineering >> > version, but in a different branch: >> > >>> https://github.com/svanderburg/npm2nix/tree/reengineering2 [2] [2] >>> >> > There is a README.md file that describes how to use it and >> > demonstrates a few common use cases. >> > >> > The flat module installation works for many of my packages but it is >> > still not 100% perfect. My blog post describes some of its >> > limitations. >> > >> > Anyway, I'm announcing this new version so that I can gather >> > feedback. Maybe this new implementation is not what people are >> > actually looking for, but I'm eating my own dogfood with it now and >> > for all my own projects it works fine. >> > >> > Regards, >> > >> > Sander >> > >> > >> > >>> Links: >> > ------ >> > [1] >> > >> > http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html [1] >> > [2] https://github.com/svanderburg/npm2nix/tree/reengineering2 [2] >> > >> > _______________________________________________ >> > nix-dev mailing list >> > [email protected] >> > http://lists.science.uu.nl/mailman/listinfo/nix-dev [3] >> >> _______________________________________________ >> nix-dev mailing list >> [email protected] >> http://lists.science.uu.nl/mailman/listinfo/nix-dev [3] Links: ------ [1] http://sandervanderburg.blogspot.com/2016/02/managing-npm-flat-module-installations.html [2] https://github.com/svanderburg/npm2nix/tree/reengineering2 [3] http://lists.science.uu.nl/mailman/listinfo/nix-dev
_______________________________________________ nix-dev mailing list [email protected] http://lists.science.uu.nl/mailman/listinfo/nix-dev
