Add a Scalafix migration for sbt-tpolecat v0.5.0

[DavidGregory084]

This PR adds a Scalafix migration for sbt-tpolecat v0.5.0, which will migrate many of the symbols in the project to a new package.

[DavidGregory084]

One thing to note - there is already an artifact migration in place for this project.

Do I need to use the old or the new group ID in the Scalafix migration?

[codecov]

Codecov Report

Patch and project coverage have no change.

Comparison is base (e034a17) 91.03% compared to head (ebc5ae7) 91.04%.

Additional details and impacted files

@@           Coverage Diff           @@
##             main    #3126   +/-   ##
=======================================
  Coverage   91.03%   91.04%           
=======================================
  Files         162      162           
  Lines        3404     3406    +2     
  Branches      311      315    +4     
=======================================
+ Hits         3099     3101    +2     
  Misses        305      305           

see 1 file with indirect coverage changes

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[fthomas]

One thing to note - there is already an artifact migration in place for this project.

This artifact migration is going into effect for the first time with version 0.5.0, right? No prior version uses the new groupId?

Do I need to use the old or the new group ID in the Scalafix migration?

If the answer to the above is yes, then you need to use the old groupId for the Scalafix migration.
See for example these two other artifact + Scalafix migrations that migrated to a new groupId: #2615, #1967

[DavidGregory084]

If the answer to the above is yes, then you need to use the old groupId for the Scalafix migration. See for example these two other artifact + Scalafix migrations that migrated to a new groupId: #2615, #1967

Ah perfect, thanks for the examples @fthomas! I've changed the migration to use the old group ID now as indeed this is the first release using the new group ID.

[fthomas]

👍

[fthomas]

The Scalafix migration is used for the update to 0.5.0, but I've seen it failing because the SemanticDB is missing for the files it tried to fix:

2023-07-27 05:19:31,943 INFO  Process update io.github.davidgregory084:sbt-tpolecat : 0.4.4 -> 0.5.0
2023-07-27 05:19:34,292 INFO  Create branch update/sbt-tpolecat-0.5.0
2023-07-27 05:19:34,343 INFO  Running migration ScalafixMigration(io.github.davidgregory084,NonEmptyList(sbt-tpolecat),0.5.0,NonEmptyList(github:typelevel/sbt-tpolecat/v0_5?sha=v0.5.0),Some(https://github.com/typelevel/sbt-tpolecat/blob/main/CHANGELOG.md#050),None,None,Some(Build),None)
2023-07-27 05:19:50,020 WARN  Scalafix migration failed
org.scalasteward.core.io.process$ProcessFailedException: 'SBT_OPTS=-Xss8m -XX:MaxMetaspaceSize=512m scalafix --rules=github:typelevel/sbt-tpolecat/v0_5?sha=v0.5.0 $PROJECT_DIR/version.sbt $PROJECT_DIR/build.sbt $PROJECT_DIR/project/plugins.sbt $PROJECT_DIR/project/versions.scala' exited with code 8.
error: SemanticDB not found: version.sbt
error: SemanticDB not found: build.sbt
error: SemanticDB not found: project/plugins.sbt
error: SemanticDB not found: project/versions.scala

	at org.scalasteward.core.io.process$.$anonfun$slurp$7(process.scala:78)
	at org.scalasteward.core.io.process$.$anonfun$slurp$7$adapted(process.scala:72)
	at flatMap @ org.scalasteward.core.io.process$.$anonfun$slurp$5(process.scala:72)
	at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
	at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
	at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
	at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
	at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
	at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
	at modify @ fs2.internal.Scope.close(Scope.scala:262)
	at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
	at rethrow$extension @ fs2.Compiler$Target.$anonfun$compile$1(Compiler.scala:157)
	at as @ org.scalasteward.core.io.process$.$anonfun$readLinesIntoBuffer$1(process.scala:126)
	at get @ fs2.internal.Scope.openScope(Scope.scala:275)
	at flatMap @ fs2.Compiler$Target.flatMap(Compiler.scala:163)
	at flatMap @ fs2.Pull$.$anonfun$compile$21(Pull.scala:1214)
	at update @ fs2.internal.Scope.releaseChildScope(Scope.scala:224)
2023-07-27 05:19:58,423 INFO  Push 1 commit(s)
2023-07-27 05:19:59,256 INFO  Create PR update/sbt-tpolecat-0.5.0
2023-07-27 05:20:07,208 INFO  Created PR $FORGE/pull-requests/1400

I don't know how the scalafix invocation should look like if SematicDB files are required. This is the first target: "build" migration that requires SemanticDB.

[DavidGregory084]

Hmm, I think that the meta-build will need to be compiled first as well with sbt-scalafix in project/project/plugins.sbt and scalafixEnable in project/build.sbt in order for the semanticdb files to exist, so it might be tricky to make that work with the CLI?

Perhaps we need to change runBuildMigration so that it uses the same approach as runSourcesMigration, but in the meta-build?

[DavidGregory084]

Perhaps something like this?

  private def runBuildMigration(buildRoot: BuildRoot, migration: ScalafixMigration): F[Unit] =
    OptionT(latestSbtScalafixVersion).foreachF { pluginVersion =>
      workspaceAlg.buildRootDir(buildRoot).flatMap { buildRootDir =>
        val plugin = scalaStewardSbtScalafix(pluginVersion)
        fileAlg.createTemporarily(buildRootDir / project / project, plugin).surround {
          val withScalacOptions = migration.scalacOptions.fold(Resource.unit[F]) { opts =>
            val options = scalaStewardScalafixOptions(opts.toList)
            fileAlg.createTemporarily(buildRootDir / project, options)
          }
          withScalacOptions.surround {
            val scalafixCmds = migration.rewriteRules.map(rule => s"$scalafixAll $rule").toList
            val slurpOptions = SlurpOptions.ignoreBufferOverflow
            sbt(Nel(reloadPlugins, scalafixEnable, scalafixCmds), buildRootDir, slurpOptions).void
          }
        }
      }
    }

I'll try and test this out and send a PR

[fthomas]

Perhaps something like this?

That would be nice if it works. source and build migrations would then be the same procedure but in different directories.

[DavidGregory084]

I opened #3133 with an attempt at fixing this!