I’m interested in getting the advantages of elm-format (no discussion of formatting etc), but the specific choices in elm-format don’t work for my team (in particular, we prefer a concise codebase, and we want to be consistent with our non-Elm code rather than consistent with other programs written in Elm).
Elm-format itself has chosen not to be configurable, so I’m looking for an alternative. There are 99 forks, and I worry about falling behind elm-format which seems to be blessed at this point.
Is there one partiuclar fork (or other tool) that the non-elm-format community has rallied around?
I’m not aware of a maintained alternative. What are the differences your team is looking for? In case those are simple and only a small amount, one solution I could think of, is calling elm-format, and calling a custom script for the changes in addition afterwards (e.g. correcting the indentation). Although this will get errorprone and hard to maintain easily as soon as there is a bunch of changes that should be done.
Yes, I thought about this. Not a bad idea for some of the changes (eg lining up |> with the first letter on it’s lhs).
So what I’m looking for is avoiding extra spacing and lines. The compact branch of timjs/elm-format does a lot of this, especially removing extra lines between case conditions and between functions. Some extra that I’m looking for:
dont go to newlines quite so quickly in ifs and cases (use line-length to decide)
dont add a newline before the first let-def in a let
lets with one def that fit on a line should stay on that line, including the in at the end
dont indent before |>
Ideally I’d also get to split imports into groups (core, libs, and our stuff) but I won’t die on that hill.
I used to style my Elm that way, until I hooked up elm-format to my Emacs and “Learned to Stop Worrying and Love the Bomb” (to quote Dr. Strangelove). I decided that one consistent Elm community style was more important than my personal preferences. Your mileage may vary (YMMV).
I am reminded of my short stay at the end of life of the Atari Cambridge Research Lab, in Kendall Square, Cambridge, Massachusetts, January through March of 1984. We programmed Symbolics Lisp Machines there. One of our researchers used the biggest font available on the Lisp Machine, and had a rule that a function definition had to fit on one screen at that font size. Another built his own 7-pixel-high font (five pixels above the baseline and two for descenders, leaving very little room for style decisions), and filled HIS screen with little tiny text. Different strokes. (this was before the time of scalable fonts, when the font designer specified every pixel).
These two are likely to change (at least to provide a single-line option), see elm-format#507 (case), and elm-format#209 (if).
Also, elm-format is getting close to having an AST mode which will parse and provide an AST of a given source file; possibly that would be useful for the parsing half of an alternate formatter?
I’m also open to PRs to elm-format that refactor the code in ways that will make future changes less likely to break forks.