haskell.nix VS nix-doom-emacs

If you are somewhat comfortable with nix: https://github.com/input-output-hk/haskell.nix supports GHCJS 8.10.x (in particular 8.10.7).

I also prefer stack for development, but I use nix to deploy to production. This way, I can install ad-hoc system dependencies locally and play with them during development as well as enjoy the bits and pieces of Haskell ergonomics stack affords, and once I'm happy with what I have, I "nixify" those dependencies as part of the project nix configuration and send them to production without fear. I use IOHK's excellent haskell.nix infrastructure to nixify my stack-based Haskell project, which makes it trivial to maintain a nix configuration that's always in sync with my stack configuration.

And stuff like haskell.nix is supposed to let you configure things with stack or cabal or whatever tool you find most convenient, and let nix do the rest.

/u/ItsNotMineISwear mentioned haskell.nix, which does generate a Haskell package set based on either a stack.yaml file, or the Cabal solver. This would solve some of your problems, but then possibly introduce others.

There are a bunch of open branches. And yes, there is ghcjs support in haskell.nix, see this comment.

Fine-grain depedencies are crucial, but vendoring is terrible.

Check out https://github.com/kolloch/crate2nix/ https://github.com/input-output-hk/haskell.nix for technical solutions to getting the best of both worlds.

Sorry, but there's just no way APT and RPM are going to keep up here very well.

I use this it works great.

let doom-emacs = pkgs.callPackage (builtins.fetchTarball { url = https://github.com/vlaci/nix-doom-emacs/archive/master.tar.gz; sha256 = "1g0izscjh5nv4n0n1m58jc6z27i9pkbxs17mnb05a83ffdbmmva6"; }) { doomPrivateDir = ./doom.d; # Directory containing your config.el init.el # and packages.el files }; in { home.packages = [ doom-emacs ]; home.file.".emacs.d/init.el".text = '' (load "default.el") ''; } ```