Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: move sbt-scalafmt to the TypelevelKernelPlugin #247

Closed
danicheg opened this issue Apr 7, 2022 · 6 comments · Fixed by #275
Closed

Proposal: move sbt-scalafmt to the TypelevelKernelPlugin #247

danicheg opened this issue Apr 7, 2022 · 6 comments · Fixed by #275
Milestone

Comments

@danicheg
Copy link
Member

danicheg commented Apr 7, 2022

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
Copy link
Member

armanbilge commented Apr 7, 2022

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
Copy link
Member Author

danicheg commented Apr 7, 2022

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
Copy link
Member

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
Copy link
Member Author

danicheg commented Apr 7, 2022

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
Copy link
Member

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
Copy link
Member

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.

@armanbilge armanbilge added this to the v0.5.0 milestone Apr 7, 2022
This was referenced May 17, 2022
@armanbilge armanbilge modified the milestones: v0.5.0, v0.4.10 May 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants