test/document usage of local 2.13 rules #128
Conversation
| libraryDependencies += "ch.epfl.scala" %% "scalafix-core" % Versions.scalafixVersion, | ||
| libraryDependencies += "joda-time" % "joda-time" % "2.10.6" | ||
| ) | ||
|
|
||
| val service = project | ||
| .dependsOn(rules % ScalafixConfig) | ||
| .settings( | ||
| scalaVersion := Versions.scala213, | ||
| libraryDependencies += "com.nequissimus" % "sort-imports_2.12" % "0.5.0" % ScalafixConfig | ||
| libraryDependencies += "com.nequissimus" %% "sort-imports" % "0.5.2" % ScalafixConfig |
There was a problem hiding this comment.
There was a problem hiding this comment.
By the way, I am using an external rule here as I need multiple rules, so I can't stick to example-scalafix-rule.
|
I ran into this as well following the instructions from https://scalacenter.github.io/scalafix/docs/developers/local-rules.html. Might make sense to update the instructions there as well. |
|
@jrudolph do you mean that https://scalacenter.github.io/scalafix/docs/developers/local-rules.html#prerequisite should also suggest setting the Scala version at the build level? |
Doh, I missed that part at the top :) Maybe it's enough to include the error message that you will get if you don't do it there which was a generic "Provider ... could not be instantiated". Maybe a safeguard could be built into the scalafix invocation to avoid that the classpath contains incompatible classes/jars (e.g. just look for wrong "scala_2.13" in classpath or jar file names)? Maybe that would probably not only be useful for the local rules scenario as soon as cross publishing will be more common. |
Somehow, this got lost when I addressed @olafurpg's comments. It demonstrates the second goal of #121