[Nix-dev] yet another npm2nix reengineering attempt

[Wout Mertens]

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 <svanderburg at 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 <shea at 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 at lists.science.uu.nl
>> > http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>> _______________________________________________
>> nix-dev mailing list
>> nix-dev at lists.science.uu.nl
>> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>>
>
> _______________________________________________
> nix-dev mailing list
> nix-dev at lists.science.uu.nl
> http://lists.science.uu.nl/mailman/listinfo/nix-dev
>
-- 

Wout.
(typed on mobile, excuse terseness)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160308/558a699e/attachment.html