Closed srid closed 1 year ago
Also becoming responsible for the formatter settings file themselves would expand the scope of this project quite considerably.
Maybe what we need is some sort of interface to define those wrappers.
{
# Nix for fourmolu.yaml, provided by the fourmulu-nix flake?
fourmulu.settings = {
indentation = 2;
comma-style = "leading";
record-brace-space = true;
};
# also add default args to the wrapper?
fourmulu.args = [
"--ghc-opt"
"-XImportQualifiedPost"
];
treefmt.config = {
package = pkgs.treefmt;
programs.fourmolu.enable = true;
# connect both flakes.
programs.fourmulu.package = config.fourmulu.output.package;
};
devShells.default = pkgs.mkShell { buildInputs = [ config.fourmolu.output.package ]; };
}
What do you think?
(I'm also playing with using output.package
as a special namespace to store generated wrapper)
Yea, it makes sense to decouple these things. 👍🏾
fourmolu-flake
incoming ...
What I'd like to achieve ultimately
https://github.com/srid/haskell-template/issues/76
tldr;
fourmolu
(a Haskell formatter supported by treefmt) takes a configuration file calledfourmolu.yaml
. The aforementioned issue is about replacing this YAML file with Nix.Purpose of this issue
Is this in scope for treefmt-nix? ie., can treefmt-nix itself expose these settings? As a result, the flake-module use would look like:
More general feature
The more general feature here is that treefmt-nix "nixifies" the configuration for individual formatters. Just like it can generate
treefmt.toml
(and a wrapper treefmt script), in the case of fourmolu it can also generatefourmolu.yaml
(and a wrapper fourmolu script).