DavHau
DavHau
Let's use this issue for tracking the progress on nodejs stuff. Tanslators implemented: - [x] yarn.lock translators - [x] package-lock.json translator - [x] package.json translator - [x] support yarn v2...
The most efficient method of using dream2nix in nixpkgs would probably be to just copy the whole framework into nixpkgs and let individual packages reference the code from there. But...
related: https://github.com/nix-community/dream2nix/pull/155 https://github.com/nix-community/dream2nix/pull/151 https://github.com/nix-community/dream2nix/pull/153 This is a hypothetical usage example of dream2nix if the framework was fully based on the nixos module system. This is not only useful for configuring...
This addresses the challenge of handling source trees that contain multiple software projects. These are notes/ideas for a potential `discovery phase`, which is supposed to be executed before the translation...
- Explain pattern: impure translator calls pure translator - Maybe showcase for impure only translator (no call to pure translator) - Explain how to test during development
see: https://github.com/nix-community/dream2nix/pull/164#discussion_r895712272 Also the hidden packages should be dynamically generated depending on the ghc version. This can be done by parsing this file: https://gitlab.haskell.org/bgamari/ghc-utils/-/blob/master/library-versions/pkg_versions.txt
see: https://github.com/nix-community/dream2nix/issues/117#issuecomment-1107676009
Content could be: - walk through the packaging workflow with dream2nix - show how to implement a new translator - show how to implement a builder