I wanted to see what are my options for nix code formatters, so I’ve gone googling and comparing stuff (just for a little while).
The result of this exercise was a small article with an overview of formatters + some mention of personal preferece, here it is: drakerossman.com - Overview of Nix Formaters Ecosystem
Since I wasn’t that thoroughly researching the topic, any feedback is very welcome!
Hey, co-author of the Nix formatting RFC here, I want to expand with some info:
- The RFC defines an entirely new standard for how to format Nix, it doesn’t pick an existing style, and differs completely from the original nixfmt style
- The prototype for that RFCs formatting is merely _based_on the codebase of nixfmt, mainly because it was best suited architecturally
- Since very recently, the RFC’s formatting is exposed as a Nixpkgs attribute
pkgs.nixfmt-rfc-style on unstable channels. So it’s now very easy to install and try out
- The RFC is very close to FCP and is going to make its formatting both official and enforced for Nixpkgs, so we expect that it become the community default. Minor changes to the formatting are still happening, and there are still bugs, but it’s very close.
Hi Infinisil, thank you for the update! Now, mind if I update the article with your commment with minor edits?
That would be great, feel free to!
This is so, so exciting to read. Love the efforts you’ve been driving @infinisil, thank you.
Still, alejandra is very opinionated in how it approaches formatting, and is not configurable in any sense.
Is it still printing “ads” every time you use it? Tools like this should be silent unless there’s something wrong going on.
It is worth noting, that despite the lack of fancy marketing, nixfmt also fulfills a lot of the properties alejandra claims:
- “uncompromising”, i.e., it pretty-prints the AST from scratch
- opinionated (mostly mine and Infinisil’s if you go with the RFC branch ^^ )
- correct: nixfmt has the
--verify flag which checks its output for idempotency and correct parsing. We fuzz it against the extensive test suite and the entirety of nixpkgs. We plan on adding CI that will actually use nix tooling to check that the output parses the same against the official cppnix parser. (While this is not a formal proof of correctness[^1], Alejandra doesn’t have one either)
At this point, I think that among the “uncompromising”/pretty-printing formatters,
nixfmt-rfc-style is the most polished one currently and I’d recommend using it[^2]. Among the rules-based formatters, there is only nixpkgs-fmt but I think it generally is worth a look too.
[^1]: This got me thinking though, there probably would be a way to create an engine which formally proves correctness through the type system. However currently it would be a bit useless, since we lack a formal specification of the Nix grammar and semantics to prove against.
[^2]: Or forking it to make it match your own opinions. The nixfmt engine is the most maintainable and malleable of the code bases we tried, that’s also why we use it as basis for our RFC.
Hi piegames, and thanks for the message.
I wanted to update the article with your input too (if you allow so), but since you also suggest
nixfmt-rfc-style is the most polished formatter currently having near feature-parity with
alejandra, could we maybe also hope to get an opinion from @kamadorueda ?
feel free-----------(Post must be at least 20 characters)