(our prior most recent statement on this (in November 2016) was https://github.com/scala/scala-abide/issues/69#issuecomment-261976673)
At the time Abide started, way back in 2014, the Scala Center didn’t exist yet, Scalafix didn’t exist yet, and Scala.meta didn’t have a semantic API yet. Eugene Burmako wasn’t even born yet! (That’s not true, he just didn’t have his Ph.D.)
The situation now is very different. Scalafix exists and is moving full steam ahead at the Scala Center. Recent versions of Scalafix use Scala.meta’s new semantic API to support rewrites that take types into account, not just syntax.
Scalafix was originally conceived as a Scala 2 -> Dotty rewrite tool, but at Lightbend we think it will be also be useful and important as a tool for rewriting Scala 2.11/2.12 code for Scala 2.13 and beyond. (At the last Scala Center advisory board meeting, I got the impression that this was sinking in, though Scalafix’s readme and docs don’t reflect it yet.)
But what do Scalafix and Abide have to do with each other? Well, a Scalafix rule identifies problematic pieces of code and rewrites them. A linter like Abide identifies problematic pieces of code and… stops. Doesn’t rewrite them, just complains about them.
So it seems to me that we can discard Abide now, and that Scalafix ought to take its place as our next-generation linter. A linter rule can just be a rewrite rule without the rewrite part.
After all, why Abide started, what distinguished Abide from other linters, was that it used scalac’s actual parser and type-checker. But thanks to Scala.meta’s semantic API, Scalafix now uses them too, and makes it nicer for rule authors to interact with them.
I’m suggesting this in public for the first time. In particular, I haven’t run the idea by Olafur (author of Scalafix) yet. Oh wait, I guess just did. Hey Olafur, hey Scala Center, what do you think? Do you see any reason why Scalafix shouldn’t be our new linter too?