Closed ghost closed 4 years ago
This would only leave the yarn2nix CLI which is a very small part of the project. It would also mean that this project's logic would be split between two repositories. As you can see from the git history, most of the changes are actually happening in mkYarnPackage and associated nix functions.
In that case, we might as well merge everything into nixpkgs.
The idea is to handle yarn2nix in a similar fashion as bundix and vgo2nix. The important point here is that every file should only have one single source of truth. In the past people have changed yarn2nix files in nixpkgs without adding the changes here, so this is something people are concerned about. In my opinion there was no big problem with keeping the copy of yarn2nix in sync via the update-script, but @flokli convinced me that it would be an improvement.
Another step would be removing the js files from nixpkgs as well and package them like every other application.
Yeah, many of these tools have their "code generation code" inside their own repo, made available as a regular package, and possible "helper nix code" used to build packages in $language living in the nixpkgs repo.
The latter needs to live in nixpkgs, so that packages can actually be built. This PR only decreases the amount of duplicated code. We can still decide on where to put the Javascript code once the dust has settled a bit :-)
@flokli if you think it's a good idea, let's merge this
The Nix file for mkYarnPackage must be in the nixpkgs repository, because Hydra does not allow importing Nix files from downloaded paths. To prevent the nixpkgs version of the Nix code from getting out-of-sync with this repository, let's remove it here and use nixpkgs as the single source of truth for the Nix code. Incompatibilities in the interface can be dealt with by adding an attribute for the yarn.nix file format version in the future.