Change:
subModuleMerge = path: vals: lib.fix (args: let <del> result = recurseInto path (opt.options ++ toList vals) args; </del> <ins> result = recurseInto path (opt.options ++ imap (index: v: args: { key = rec { #!!! Would be nice if we had the file the val was from option = path; number = index; outPath = "option ${option} config number ${toString number}"; }; } // (lib.applyIfFunction v args)) (toList vals)) args; </ins> name = lib.removePrefix (opt.name + ".") path; extraArgs = opt.extraArgs or {}; individualExtraArgs = opt.individualExtraArgs or {};

Discussion:
On (), this fails: with Based on , maybe wants to know about this?
Unfortunately we don't always keep in a compilable state, but if you (or anyone else) is interested in fixing this, we would appreciate PRs fixing it up.
Is there some form of CI that would check whether it is compilable and maybe help identifying what broke it?
Not really. There is which will compile whenever someone sends a PR specifically for it. There is also , which runs builds for the various derivations in nixpkgs, but unfortunately it doesn't run all builds on all PRs (which would be too expensive). So most people don't have a good idea when different builds break. (I was planning on linking you to the GHCJS derivations on Hydra, but it is so slow, I'm not actually able to find a good link for you. If you go to and type in to the search box, you might get lucky and it will load for you. I believe you should be able to use this to go back in time and figure out when the GHCJS builds broke. Although Hydra's interface doesn't necessarily make this easy.) There are a few people who watch/review Haskell-related PRs here on nixpkgs, but we're often not too careful about the GHCJS builds. I don't think any of us use it. There are also a few other people who often send PRs to the Haskell infrastructure ( etc), but I am not sure if any of them rely on the GHCJS builds. I don't have a good solution for how to keep the GHCJS builds healthy, other than someone specifically keeping an eye on it. Although if all you're interested in is fixing the immediate build problem, you could try ing your way to the commit responsible for the breakage. I imagine the GHCJS builds have been working at least in the last couple months or so?
Oh, the Hydra search results just loaded. I think this is the GHCJS build on nixpkgs : It looks like this was the last successful build: This was the first failure build after this success: You might have to first look to see if that failure is the same one you're seeing locally. If it is, then you could try to figure out what commit caused it.

If that failure is not the same one you're seeing locally, then I'm not sure the best way to go about figuring out what broke it.
Thanks! Unfortunately, that was a weekend project, so probably won’t get to it until the next weekend where I will work on that… and pinning an old version of nixpkgs works around the problem nicely.
Are there any updates on this? I was hoping to upgrade to a newer nixpkgs to get cabal 3, but I don't know of a good working commit.
Ran into this as well. Found out that builds fine on the branch (commit currently). Hydra builds for it can be found here: Interestingly, neither of the commits on that pointed out - (the last successful one) and (the first failing one) - are ancestors of : I guess that means that contains some older packages. The version number of ghcjs is the same as in , though - 8.6.0.1.
FYI, published a PR that should resolve this issue:
Hopefully