Proposal: move sbt-scalafmt to the TypelevelKernelPlugin

[danicheg]

I think that sbt-scalafmt is the base plugin for every Typelevel project. So I opine it's natural to move it to the most upstream Typevel* plugin (I guess it's the TypelevelKernelPlugin). WDYT?

[armanbilge]

Well, not every project :) e.g. https://github.com/typelevel/shapeless-3 and maybe some others I forget.

Also, there are projects outside Typelevel that use the plugin but don't like using scalafmt, such as @davenverse and tpolecat-verse.

Is your proposal just that we add the dependency, or that we also add the CI integration? The TypelevelKernelPlugin also doesn't know about GH actions, that's also in a separate plugin 😅

I think the long-term goal should be that all Typelevel projects use sbt-typelevel instead of sbt-typelevel-ci-release. Then it doesn't matter where the formatting plugin is. But, then they should also start using copyright headers.

[danicheg]

Analogically that client is getting sbt-mima-plugin transitively from sbt-typelevel-ci-release, it'd be cool to get something the same with sbt-scalafmt. Just because the formatting looks like something base.

[armanbilge]

it'd be cool to get something the same with sbt-scalafmt

Btw sbt-scalafmt is already included in the core sbt-typelevel plugin. If you want sbt-scalafmt, you should probably use sbt-typelevel (not sbt-typelevel-ci-release :) Does that address your use-case?

[danicheg]

That was my point - to not use the most powered plugin because I need a little thing (formatting) from it. And it seems possible to move down the formatting plugin within the Typelevel plugins hierarchy.

[armanbilge]

Right, b/c there are some things in the powered plugin that you do not like? :) The problem is, there are people who also don't like formatting, and I think it's important for sbt-typelevel to be useful to them as well. Nobody agrees on anything! :)

What I think could make this easier is to extract an sbt-typelevel-ci-scalafmt plugin. So then anyone can add it to their build easily. I originally tried this in http4s/sbt-http4s-org#120 (comment) but I ran into some problems because of sbt non-determinism.

Btw, FTR I would really like to solve this. I just don't know how.

[armanbilge]

Ok, I have an idea how to fix this :)

We can use sbt "reflection" in the sbt-typelevel-ci plugin to check if the scalafmt, header, and mima plugins are enabled in the build. If they are, we can add the steps to CI automatically.

Note this means we won't actually add these dependencies; they will still have to be added somewhere else. However, if they are present, then CI will configure itself automatically.