I have open-source projects on which I use elm-format. Sometimes I merge PRs from people who don't use elm-format, only to discover later that I've ended up with elm-format diffs. These are annoying, especially if I've already started coding and don't realize I have diffs to clean up (ideally in a separate commit), at which point I have to double back and fix them before proceeding with what I actually want to be doing.
It would be better to be able to handle these proactively, by adding something like an elm-format --verify step to my Travis config which would fail the build if elm-format would produce any diffs with the current file structure.
Add a --verify flag to the CLI. When set, instead of generating any actual files, elm-format instead compares what it intends to generate with what's currently on the file system.
The CLI output is either:
@rtfeldman Here is what's implemented:
Docs:
--validate Check if files are formatted without changing them.
Output of elm-format file.elm --validate when file is formatted (exit code 0):
Processing file file.elm
Output of elm-format file.elm --validate when file is not formatted (exit code 1):
Processing file file.elm
File would be changed file.elm
I think the output format can/should be cleaned up a bit, but that should probably be a separate issue.
Awesome!!! 馃帀 馃帀 馃帀
Can't wait to integrate this into my builds! 馃樃
Is worth flagging up that if anyone is running elm-format with the --validate flag in travis CI then it is well worth using the solution mentioned in https://github.com/elm/compiler/issues/1473#issuecomment-245704142 to speed up the linting which will otherwise take an exceptionally long time.
Most helpful comment
@rtfeldman Here is what's implemented:
Docs:
Output of
elm-format file.elm --validatewhen file is formatted (exit code 0):Output of
elm-format file.elm --validatewhen file is not formatted (exit code 1):I think the output format can/should be cleaned up a bit, but that should probably be a separate issue.