The Uncompromising Nix Code Formatter

This is the only way forward once you pass certain lines of code threshold, and it’s a good idea from an architectural and cognitive overhead point of view

I migrated a big codebase in the past. My two cents is that the best approach is putting lines of code directly in the general public hands, i.e. on Nix’s master, no feature flags, and it’s more valuable to have 1 line of code migrated this way than to have 1000 “migrated” under a feature flag (i.e. duplicated), or separated from the general public hands (i.e. a fork)

I believe a refactor like this needs an RFC and getting the approval from the code owners. If we could get that, I would personally put time into migrating code

4 Likes

Coolest, fastest, and nicer release of all!

Formatting Nixpkgs in 3 seconds:

Peek 2022-02-28 19-07

And even code simplification:

--- a/lib/customisation.nix
+++ b/lib/customisation.nix
@@ -167,7 +167,7 @@
     commonAttrs =
       drv
       // (builtins.listToAttrs outputsList)
-      // ({all = map (x: x.value) outputsList;})
+      // {all = map (x: x.value) outputsList;}
       // passthru;
--- a/lib/generators.nix
+++ b/lib/generators.nix
@@ -15,7 +15,7 @@
  * Documentation in the manual, #sec-generators
  */
 {lib}:
-with (lib).trivial; let
+with lib.trivial; let
   libStr = lib.strings;
   libAttr = lib.attrsets;

More expressive code with inline comments:

    inherit
      (callPackage ../development/tools/ocaml/ocamlformat {})
-      ocamlformat
-      # latest version
+      ocamlformat # latest version
       ocamlformat_0_11_0

And many more!

5 Likes

In the last example, how do you know the comment was not referring to the line below?

8 Likes

Agreed, I think the universal convention in code I’ve read in any other language is to write the comment before the line it describes, not after.

4 Likes

Looking at the code, this doesn’t pull comments up before the previous line, but actually just keeps comments inline if they already were inline (which was a frequently requested feature; I do this a lot too when writing nix for some reason; maybe because lists are so common and tall?).

I imagine the diffs are for formatting before and after the 7.0 release, rather than directly on nix code, but that could be stated more clearly :wink:

3 Likes

Wow this has come such a long way! It’s amazing what not even 2 months of actually listening to constructive feedback can bring. Great job @kamadorueda and thanks for your work on this! And everyone who helped in some way or another, of course.

11 Likes

The smell of freshly baked bread is always good for the body!

8 Likes

Which elements should the Alejandra CLI have?

  • Path of changed files
  • Error messages, if any
  • Colored output
  • Progress bar
  • Stats at the end
  • Minimal output, Unix philosophy

0 voters

“Show the code context of an error message, so that I can quickly find the issue in the file.”

I wonder if that is meant by error messages?

Just wanted to say that the README and website for this project were A+ in describing the intent and motivation.

1 Like

Some improvements to the CLI have landed the main branch in order to make it more pleasant to use:

In particular, the elements that people identified as less useful were removed, the elements people identified as useful were polished, the screen is not cleared anymore, the output is more minimalistic by default, and Vim users can now use :%!alejandra -qq (double q) to format the current buffer, even if it contains syntax errors

Also, now certain sponsor tiers allow companies to advertise their offerings to active Nix users by placing a small ad at the end of Alejandra’s terminal output, and also some thank you messages were included for the sponsors and contributors of the project.

Congratulations! Your code complies with the Alejandra style.

👉 [Sponsored] Advertise your company here, reach lots of active Nix users!
More information at: https://github.com/sponsors/kamadorueda

It would be nice if you help me test these changes before cutting a 3.0 release,

Thank you!

2 Likes

While I understand the sponsorship advertisement on Github, being shown one on CLI is bit tough to swallow. Even then, it would be acceptable for Alejandra the standalone tool. If Alejandra gets accepted as de-jure formatter via RFC I would not like an advertisement in default Nix behavior.

9 Likes

That’s a really cool feature :smiley:

1 Like