Great job Sander! Some thoughts:
- Node 5 layout is Node 4 compatible, so why not use only that? - You can symlink the first level of modules instead of the modules themselves to avoid the commonjs derefence thing. So a combination of modules becomes a shallow copy. - npm2nix doesn't have to support cycles and conflicting versions. Having a local node_modules in the project for those pathological cases is always an option. Better to only support clean and sane dependency graphs. - npm2nix doesn't have to generate the same output as npm. It just needs to generate something that matches the package.json declarations when loaded into Node… I think that if you limit what npm2nix does, it will be a lot easier to handle… Wout. On Tue, Mar 1, 2016 at 3:12 PM Sander van der Burg <svanderb...@gmail.com> 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 <s...@shealevy.com> 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]), 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] >> > >> > 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 >> > [2] https://github.com/svanderburg/npm2nix/tree/reengineering2 >> > >> > _______________________________________________ >> > nix-dev mailing list >> > nix-dev@lists.science.uu.nl >> > http://lists.science.uu.nl/mailman/listinfo/nix-dev >> >> _______________________________________________ >> nix-dev mailing list >> nix-dev@lists.science.uu.nl >> http://lists.science.uu.nl/mailman/listinfo/nix-dev >> > > _______________________________________________ > nix-dev mailing list > nix-dev@lists.science.uu.nl > http://lists.science.uu.nl/mailman/listinfo/nix-dev > -- Wout. (typed on mobile, excuse terseness)
_______________________________________________ nix-dev mailing list nix-dev@lists.science.uu.nl http://lists.science.uu.nl/mailman/listinfo/nix-dev