[Nix-dev] yet another npm2nix reengineering attempt

[Shea Levy]

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
<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]
>>> [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
>> > nix-dev at lists.science.uu.nl
>> >
http://lists.science.uu.nl/mailman/listinfo/nix-dev [3]
>> 
>>
_______________________________________________
>> nix-dev mailing
list
>> nix-dev at lists.science.uu.nl
>>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.science.uu.nl/pipermail/nix-dev/attachments/20160301/cd977725/attachment.html