Add Spotless plugin support

[ayewo]

This PR adds official support in Mill for a SpotlessModule via the addition of 3 Spotless traits:

• JavaSpotlessModule
• KotlinSpotlessModule and
• ScalaSpotlessModule

which can be used with JavaModule, KotlinModule and ScalaModule respectively. This is because each of those 3 JVM languages have different 3rd-party dependencies.

It works similar in style to PalantirFormatModule.

This is intended to close #3888

[lihaoyi]

Is there some way to configure whether Spotless uses ktfmt or ktlint? AFAIK both of them provide formatters. Or is Spotless hardcoded to use one or the other?

[ayewo]

There's is currently no way to configure whether Spotless uses ktlint. It's currently set as the default.

If a valid config for ktfmt is provided via KotlinConfig(...) in the build.mill, then ktfmt will also be used, alongside the default formatter i.e. ktlint.

You want both of them to be configurable?

[lihaoyi]

No need then, I think we can just follow the upstream convention

[ayewo]

Based on your answer, it sounds like you were asking about upstream Spotless, not my implementation?
My answer was regarding my implementation.

If you were specifically asking regarding the Spotless project, this is how they do it for Kotlin:

  kotlin {
    // by default the target is every '.kt' and '.kts` file in the java sourcesets
    ktfmt()    // has its own section below
    ktlint()   // has its own section below
    diktat()   // has its own section below
    prettier() // has its own section below
    licenseHeader '/* (C)$YEAR */' // or licenseHeaderFile
  }

In the example build.gradle file above, the presence of ktfmt() would correspond to the invocation of the default version of ktfmt via this config method ktfmt().

  kotlin {
    ktfmt("0.51") 
    ...
  }

In the example above, passing a specific version i.e. ktfmt("0.51") would invoke a similar config method that takes a version argument: ktfmt(String version).

  kotlin {
    licenseHeader '/* (C)$YEAR */' // or licenseHeaderFile
  }

In this example, ktfmt will be skipped entirely since it is completely absent from the steps.

[ayewo]

Following the upstream convention would mean refactoring KotlinConfig and similar case classes to look like this:

case class KotlinConfig(
    target: String = ".kt",
    licenseHeader: Option[String] = None,
    licenseHeaderFile: Option[String] = None,
    override val licenseHeaderDelimiter: String = "(package |@file|import )",
    ktfmt: Boolean = false,
    ktfmtVersion: String = "0.53",
    ktfmtOptions: Option[KtfmtOptions] = None,
    klint: Boolean = false,
    klintVersion: String = "1.5.0"
) extends JVMLangConfig {
  require(
    !(licenseHeader.isDefined && licenseHeaderFile.isDefined),
    "Please specify only licenseHeader or licenseHeaderFile but not both"
  )    

  def ktfmt(): KotlinConfig =
    copy(ktfmt = true)

  def ktfmt(version: String): KotlinConfig =
    copy(ktfmt = true, ktfmtVersion = version)

  def ktfmtOptions(options: KtfmtOptions): KotlinConfig =
    copy(ktfmtOptions = Some(options))

  def ktlint(): KotlinConfig =
    copy(klint = true)

  def ktlint(version: String): KotlinConfig =
    copy(klint = true, klintVersion = version)
...
}

With this change, ktlint would no longer added as a formatter step by default.

[lihaoyi]

I think the config looks fine as is. Let's drop the with updaters as mentioned earlier, then we can merge it

[lihaoyi]

Is there a reason you want to use forwarders rather than using the .copy method directly?

[ayewo]

No reason other than I thought you wanted it to be similar to the style of Spotless in Groovy.

[lihaoyi]

Let's use the .copy methods directly then. We need to find a balance between the upstream style and the local Scala style, and in this case I think .copy wins out

[ayewo]

I've updated to use .copy() directly now.

[ayewo]

@lihaoyi Anything else left for this to be merged ?

[lihaoyi]

We should not need to use .copy here at all I think, we can just use the GoogleJavaFormat(...) constructor. Same as the others?

[ayewo]

Removed as requested.

[lefou]

I'd prefer to have the top-level classes in their own files.

[ayewo]

@lefou Done.

[lefou]

Where does this version come from? Is this the newest version? Do users expect it to stay stable or use always the newest?

We should not hardcode any versions. We either should leave it undefined or use a BuildInfo value that comes from the outer Mill build. That way, we can keep it up-to-date more easily.

[lefou]

Same as for googleJavaFormatVersion, versions should not be hardcoded. Have a look at PR #4552, which replaces another instance of a hardcoded version.

[lefou]

Should not be hardcoded. This version is already managed.

mill/kotlinlib/src/mill/kotlinlib/ktfmt/KtfmtModule.scala

Line 26 in facbe11

Versions.ktfmtVersion

[lefou]

Use managed Versions.ktlintVersion instead.

[lefou]

Don't hardcode versions. This should be undefined or managed from the outer build.

[lefou]

Don't hardcode versions.

[lefou]

Don't hardcode versions.

[lefou]

Don't hardcode versions. These are already available via the Versions object.