Replace Scalariform with Scalafmt

[ruippeixotog]

Scalafmt is more modern, more popular and better maintained than Scalariform. Moreover it has integration with multiple editors and IDEs. In this PR we do the plugin change and reformat all files.

I don't have strong opinions about most style settings, but I prefer to stay as close as possible to scalafmt defaults, as they're likely closer to most other projects making the code base more approachable. Therefore, I intentionally did not try to make scalafmt behave the same as scalariform. I opted to change the defaults for align (despite not being default it's recognized by scalafmt to be easier for diffs) and for maxColumn (no one needs 80 chars per line anymore and it actually makes code harder to read IMO). Let me know if you feel strongly for any of the other options :)

The PR is split in two commits, in case you only care about the plugin change and not about all the reformatted code.

[pureconfig-bot]

Warning: the content of the PureConfig website changed with this pull request. This may be intentional (as is the case when sbt-microsites is updated or some breaking change occurs) or may be an unexpected change in the library's behavior. Please check the logs of the diff_website job in the Travis build to see the differences.

[leifwickland]

Thanks for doing this. The time has come.

I'm fine with the default formatting. I'd be fine increasing the max line length to 120, but feel free to leave it as is.

Please consider adding a step to the build process which ensures that the code is formatted before any compile takes place by calling scalafmtCheckAll and scalafmtSbtCheck.

[ruippeixotog]

I'm fine with the default formatting. I'd be fine increasing the max line length to 120, but feel free to leave it as is.

Nice, I also prefer 120 :) I think @jcazevedo is ok with it too.

Please consider adding a step to the build process which ensures that the code is formatted before any compile takes place by calling scalafmtCheckAll and scalafmtSbtCheck.

I believe we already check this in our CI indirectly - after we run all the steps (including compiling, which automatically formats files) we run git diff --exit-code.

This was originally intended to catch both bad formatting and outdated tut-generated files. Do you see value in having an explicit step prior to compilation that just checks formatting? While it can be clearer for users to know what went wrong, it would prevent them from seeing compilation errors in the first round (which are arguably more important).

[leifwickland]

@ruippeixotog I'd forgotten we had the git diff check. I have a light, but easily abandoned, preference to check the formatting before compile so that the root cause of the problem is reported directly to the user, rather than requiring the user to make an inference. Feel free to leave it as is.

[pureconfig-bot]

Warning: the content of the PureConfig website changed with this pull request. This may be intentional (as is the case when sbt-microsites is updated or some breaking change occurs) or may be an unexpected change in the library's behavior. Please check the logs of the diff_website job in the Travis build to see the differences.

[ruippeixotog]

@ruippeixotog I'd forgotten we had the git diff check. I have a light, but easily abandoned, preference to check the formatting before compile so that the root cause of the problem is reported directly to the user, rather than requiring the user to make an inference. Feel free to leave it as is.

I agree with providing more direct feedback to the user. My concern is on frustrating contributors by not notifying them of everything at the first chance - it's a bit annoying to have a build fail because of formatting issues, push a commit to fix it just to be notified later that a test is also failing or tut is not synced. We could have a parallel GitHub Actions job just for formatting, but it seems a bit overkill, since a job spins a full fledged Docker container (in this case three due to the matrix build).

Anyway, I added this extra step. I'll assume most sensible people compile the project before submitting a PR :)