CLI tool

[moretea]

This cli tool should make installing yarn redundant.

---

Generate default.nix + yarn.nix

$ yarn2nix init

---

Generate default.nix + yarn.nix

$ yarn2nix warm-store

1. Run yarn install in a temporary directory to download the sources in parallel

2. Load these sources into the nix-store.

Update dependencies in yarn.nix

1. User modifies packages.json

2. Run yarn2nix update. This will run yarn lock and update yarn.nix

   Generate temporary shell environment to play around with a package

   $ yarn2nix shell

   In a tmp dir:

3. Run yarn lock
4. Generate a temporary yarn.nix
5. Run yarn2nix warm-store
6. Generate a shell.nix, taking into account the pkgConfigs.

7. exec nix-shell

[manveru]

Just noting down some things I would love to have nicer commands for:

Updating yarn.nix:

rm -rf node_modules
$(nix-build '<nixpkgs>' --no-out-link -A yarn)/bin/yarn --ignore-scripts --ignore-engines
rm -rf node_modules
$(nix-build ./nix/yarn2nix.nix --no-out-link -A yarn2nix)/bin/yarn2nix > yarn.nix

Adding (or removing) a dependency:

rm -rf node_modules
$(nix-build '<nixpkgs>' --no-out-link -A yarn)/bin/yarn add --ignore-engines --ignore-scripts standard
rm -rf node_modules
$(nix-build ./nix/yarn2nix.nix --no-out-link -A yarn2nix)/bin/yarn2nix > yarn.nix

I think it might be easiest to have a yarn alternative command which basically copies the package.json and yarn.lock to a temporary directory and performs the action there, then copying the yarn.lock back. That way we can avoid nuking the node_modules repeatedly.

[moretea]

Yep, that's what this CLI tool should do :)

I'd still like to implement some magic for the yarn shell command to make it as fast as possible (whilst giving up some purity) It should have a --pure flag to force creation from scratch.

[zimbatm]

It's possible to avoid generating the yarn.nix file, that would make one less file to have to worry about. It also means that frontend devs can keep using yarn as a developer tool and not be forced to install nix. Yarn has many more features that are useful to developers like yarn add, yarn link, ... it's probably a lot of effort to re-implement all of it.

In that regard I think that yarn2nix could be restricted to being a supporting tool for the packaging bit. As a NixOS user I also think that it would be enough if nix-shell brought the build dependencies into the environment (and yarn) but still install the node packages using yarn since it's so much faster during development. It means that we can also avoid the issues with the mutability of node_modules since it would exclusively be managed by yarn.

[moretea]

Hmm. How would we solve things like native extensions then?

[manveru]

Well, if we concentrate on just the packaging bit, the existing pkgConfig can handle pretty much all native extensions we know of. I agree that using yarn2nix purely for deployment makes a lot of sense, I just enjoy that when I switch git branches, I automatically get the appropriate environment inclusive node_modules, but using just yarn with some hook in direnv might be way faster after all.

[zimbatm]

@moretea on NixOS, the nix-shell would bring in the buildInputs extracted from the pkgConfig attribute.

[moretea]

@zimbatm are you referring to a global pkgConfig in nixpkgs? That might just work