scapegoat-scala
Scala 3 support
Hi Scapegoat team and contributors!
As some of you may have seen in my comments on PR #858 I have been working on porting Scapegoat rules to Scalafix to make the linter compatible with Scala 3 but also with the future of Scala, with the use of Scalameta. I have ported 52 rules for now, all were succesfully tested with unit tests and on a large codebase, with more coming.
Since some of you seemed interested in collaborating but things weren't moving, I figured I'd create an issue to discuss potential collaboration. How do you want to go ahead? Here are my thoughts: since I am using a completely different framework (Scalafix + Scalameta), it seems complicated to me to integrate directly into the Scapegoat code. The easiest solution would simply be to link to my repo, but I am not sure this is ideal, especially if you are planning more rules. I'd be happy to hear your thoughts in the comments.
Hi @t1b00, sorry for getting back so late. I really like the work you put into porting Scapegoat rules to Scalafix! 😃
Scalafix indeed seems like the more long-term sustainable foundation than separate macros for Scala 2 and Scala 3.
since I am using a completely different framework (Scalafix + Scalameta), it seems complicated to me to integrate directly into the Scapegoat code
Agreed.
The easiest solution would simply be to link to my repo
I think that's okay once we reached feature parity.
I am not sure this is ideal, especially if you are planning more rules
Feature development is going slow. We're mostly doing maintenance with dependency bumps. Focus is on porting migrations from Scala 2 to Scala 3. We could, however, use the resources to port rules to Scalafix. I'm happy to support with that. Maybe we should have a ticket to track progress of missing features?
I'll re-iterate a bit what I said here as well https://github.com/scapegoat-scala/scapegoat/pull/858#issuecomment-2286309943 but to me one of the most powerful features compared to the other linters that seems to be unique to Scapegoat is it's reporting capabilities.
Linters that break the built are notoriously difficult to onboard on any sizable project if not done so from the start. Being able to only get warnings and in a report that we can integrate into our chosen CI (Gitlab Code Quality / SonarQube external reports, etc) allows us to monitor and gradually reduce the issues in freshly touched code over time. I think this area would be the biggest question mark how that would work with a Scalafix based solution over being our own compiler integration.
Another aspect that would be of interest is easy of configuration. For Scapegoat it's "on by default" where you get everything unless you go into selectively enabling configurations. Whereas Scalafix seems to be (at least as far I've used it) selectively enabled only. Maybe one slight sample, within my company we publish an internal sbt plugin with our common configurations (similar to sbt-typelevel) where we also include a few constant lists with scapegoat rules as a guided opinionated rulesets for different project criticality.
Note that I'm not trying to say that Scalafix can't work / isn't the right way here. The initial support in scapegoat has for Scala 3 does show that not relying on the common semantic db format incur a heavy cost on maintenance (but probably we get power from not having the extra abstraction, but is that worth it?). So I do think it's good to explore the direction, but I also believe it's not as simple as just porting the inspections and we'll get a close-enough experience to what we get now.
Agreed, it’s more complicated.
Linters that break the built are notoriously difficult to onboard on any sizable project if not done so from the start. Being able to only get warnings and in a report that we can integrate into our chosen CI (Gitlab Code Quality / SonarQube external reports, etc) allows us to monitor and gradually reduce the issues in freshly touched code over time. I think this area would be the biggest question mark how that would work with a Scalafix based solution over being our own compiler integration.
That’s a very good argument. I checked the documentation of Scalafix and didn’t find a way to just report a warning. Maybe @t1b00 knows if that’s possible?
For Scapegoat it's "on by default" where you get everything unless you go into selectively enabling configurations. Whereas Scalafix seems to be (at least as far I've used it) selectively enabled only. Maybe one slight sample, within my company we publish an internal sbt plugin with our common configurations (similar to sbt-typelevel) where we also include a few constant lists with scapegoat rules as a guided opinionated rulesets for different project criticality.
It’s possible to bundle Scalafix-enabled rules into an sbt-plugin (IIRC) that you could depend on in your plugin.
probably we get power from not having the extra abstraction, but is that worth it?
I interpret https://github.com/dedis/scapegoat-scalafix/issues/2 such that ScalaMeta is limited compared to compiler macros. The question is if that’s just rare cases and could maybe supported in future versions.