typelevel
Shared scalafmt config?
Possibly a good idea, or a very bad one. But I am tired of copying variations of this file around my repos, and scalafmt updates change stuff all the time which means settings can get stale quickly.
This is a bit annoying to implement: it seems the correct way to do it would be to check-in a generated .scalafmt-common.conf (it would have to be managed/validated in CI like the ci.yml generated workflow).
Then every repo would have a .scalafmt.conf with the following contents:
include ".scalafmt-common.conf"
I believe this would give a repo the freedom to overwrite settings and/or completely ignore the common ones.
One of our teams at work does something like this and seems to like it.
It makes me sad how many defaults we all override, but projects have their reasons. No vertical alignment, trailing commas, and import-per-line (which I think comes from organize imports) are all useful for branching or busy projects where diffs should be minimized, but none are default.
Why is this a plugin issue rather than a template issue? Doing it here lets projects stay current, but any changes we make could cause churn on dozens of projects. And if we're just fixing deprecated settings, could that be a Scala steward or scalafix issue?
And if we're just fixing deprecated settings, could that be a Scala steward or scalafix issue?
It's not just deprecated settings. Consider the unsatisfactory changes in https://github.com/typelevel/cats/pull/4116, which resulted in new configuration options being added to scalafmt in https://github.com/scalameta/scalafmt/pull/3080. Maybe we'd want to adopt those org-wide?
Doing it here lets projects stay current, but any changes we make could cause churn on dozens of projects.
Absolutely. Nowadays any scalafmt update seems liable to do that.
I do agree that the tradeoff to manage it remotely is probably not worth it. We can have a good config in the template and projects can manage independently post-initialization. No formatting config is going to be perfect.
We're trying out this concept in sbt-lucuma: https://github.com/gemini-hlsw/sbt-lucuma/blob/7cb504a7018de813fb1c8a45c782e7c33eef3b99/src/main/scala/lucuma/sbtplugin/LucumaScalafmtPlugin.scala