On Tue, Apr 25, 2017 at 3:21 AM, Sander van der Burg
wrote:
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
On Tue, Apr 25, 2017 at 12:51 AM, Profpatsch wrote:
> yarn is really just a 1:1 rewrite of node with lockfiles.
> I don’t know why people celebrate it so much,
> because it does exactly nothing differently apart from
> creating the lockfiles.
> Don’t even know why a rewrite
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
We (IOHK) are going to use yarn2nix in the future as well.
Maybe we could have a call where things stand and how to proceed?
On Tue, Apr 25, 2017 at 12:11 PM, Maarten Hoogendoorn
wrote:
> I've been working with zimbatim and manveru on a yarn2nix as well, see
>
>
> I have read the articles from Sander van der Burg, but they don't seem to
> explain why we went with "one derivation per library", which requires us to
> manually symlink things into the node_modules folder.
>
I'm not sure if you have read my blog articles correctly, but what node2nix
I've been working with zimbatim and manveru on a yarn2nix as well, see
https://github.com/moretea/yarn2nix
I'm not actively using it myself though. I would be interested in planning
a few hours to hack on this together ;)
2017-04-25 10:37 GMT+02:00 Profpatsch :
> On 17-04-25
On 17-04-25 08:20am, Benno Fünfstück wrote:
> If we get upstream to support enough for our use case, the solution should
> be much more stable.
Upstream support might be helpful,
but that’s a wholly different beast.
> Hmm, so perhaps in we can unpack the tarballs already in `phase 1` and tell
>
>
> > This would only need a feature from upstream to use cached tarballs.
>
> npm uses the following algorithm:
> 1. resolve dependencies
> 2. move dependencies as far up the tree as possible to enable sharing
> 3. unpack the tarballs into the correct dirs
> 4. link the "bin" files into a .bin
On 17-04-25 07:26am, Benno Fünfstück wrote:
> >
> > The most interesting property is, that all dependency trees
> > are linked together with symlinked, so they are cached by nix
> > on a package level:
> > https://github.com/Profpatsch/yarn2nix/blob/master/buildNodePackage.nix#L33
>
>
> Does
>
> The most interesting property is, that all dependency trees
> are linked together with symlinked, so they are cached by nix
> on a package level:
> https://github.com/Profpatsch/yarn2nix/blob/master/buildNodePackage.nix#L33
Does this caching really gain us that much? The disadvantage of
On 17-04-23 01:10pm, Benno Fünfstück wrote:
> * A simple approach to packaging NPM applications would be to split the
> package for an NPM application into two:
> - fetch: let NPM download all the dependencies. it should(?) be possible
> to make this a fixed-output derivation, as long as NPM
On Sun, Apr 23, 2017 at 6:10 AM, Benno Fünfstück <
benno.fuenfstu...@gmail.com> wrote:
> * Alternatively, `yarn` claims to be more deterministic. Can we use `yarn`
> to build all NPM packages? Or are there NPM packages that are incompatible?
>
I think this is the best way forward. Yarn is
William Casarin schrieb am So., 23. Apr. 2017 um 16:46 Uhr:
> > The fetch phase should be deterministic if we freeze the NPM index (is
> such
> > a thing possible?) and use shrinkwrap.
> > Or is this not the case? In what cases will it fail to be deterministic?
>
> This is
Benno Fünfstück writes:
> * A simple approach to packaging NPM applications would be to split the
> package for an NPM application into two:
> - fetch: let NPM download all the dependencies. it should(?) be possible
> to make this a fixed-output derivation, as long
Hello,
the nodejs infrastructure in nixpkgs looks quite complex to me. I'm sure
that there are good reasons for this. In particular, can someone answer the
following questions, as I am not intimately familar with the full NPM
ecosystem:
Both of the following approaches change the concept from
15 matches
Mail list logo