Ideas for modes in this plugin

[DavidGregory084]

Recently @BalmungSan proposed #48, which contains some ideas that I am really excited about as it heads in the direction of having different modes for this plugin.

However, the current implementation will not work consistently across versions once e.g. -Xfatal-warnings is deprecated and replaced with -Werror.

The problem is that at the moment, once our options are configured, they are just a Seq[String] in the scalacOptions key. It's difficult to work with them in a version-independent way and it's difficult to manipulate that key in general without interfering with the user's custom options.

Scala users commonly have a few option sets that they want to use:

1. A base option set that is always on which they try to make as strict as possible to catch problems during development.
2. A set of linting options that are too annoying to use during development because they trigger constantly while code is being edited, but which should be enabled in CI.
3. A set of extra release options which make compilation too slow so they are not enabled during development or CI but are used for releases.

At the moment folks don't really seem to do 3. because there is no mechanism that allows them to do that, and they deal with 2. by manually filtering String options out in build.sbt, re-importing their build all the time and trying to remember not to commit the code that does that. 😆

I have been thinking about how to resolve this and I think the answer is to disconnect this plugin from the Seq[String] interface of providing options and to ask users to provide their options via some internal model or DSL.
We can have different "modes" for different use cases (dev, CI, release) and different ways of setting the option sets for those modes, i.e. something like:

sealed abstract class ScalacOptionsMode extends Product with Serializable

case object DevelopmentMode extends ScalacOptionsMode
case object BuildMode extends ScalacOptionsMode
case object ReleaseMode extends ScalacOptionsMode

val tpolecatOptionsMode = settingKey[ScalacOptionsMode](
  "The mode to use for configuring scalac options via the sbt-tpolecat plugin."
)

val tpolecatScalacOptions = settingKey[Seq[ScalacOption]](
  "The set of scalac options that will be applied by the sbt-tpolecat plugin."
)

val tpolecatDisabledDevOptions = settingKey[Seq[ScalacOption]](
  "The set of scalac options that are disabled in development mode. You can use this setting for options that are difficult to use during development, like unused import linting."
)

val tpolecatDevModeFilter = settingKey[Seq[ScalacOption] => Seq[ScalacOption]](
  "A filtering function that can be used to disable options in development mode. You might wish to use this to disable several options at once, i.e. all options starting with -Wunused."
)

val tpolecatExtraReleaseOptions = settingKey[Seq[ScalacOption]](
  "The extra scalac options to apply in release mode. You can use this setting for options that should be applied to the release artifact, like optimizer options."
)

This would allow us to set scalacOptions via something like this and then leave it alone:

scalacOptions ++= tpolecatScalacOptions.value.map(_.name)
tpolecatScalacOptions := scalacOptionsFor(scalaVersion.value, tpolecatOptionsMode.value)

We could add tpolecatDevMode, tpolecatBuildMode, tpolecatReleaseMode commands which set the tpolecatOptionsMode to the desired value rather than interfering with scalacOptions directly.

However I'm currently not sure what ScalacOption should be or what setting those "disabled in dev" options and "enabled for release" options should look like:

tpolecatDisabledDevOptions := Seq(
  // how do I disable -Xfatal-warnings for 2.12 and -Werror for 2.13 and 3.x?
),
tpolecatExtraReleaseOptions := Seq(
  // how do I write
  // e.g. -opt:l:method, -opt:l:inline, -opt-inline-from:** for applications
  // or -opt:l:method, -opt:l:inline, -opt-inline-from:my.library.package.** for libraries
  // and have it work across Scala 2.12, 2.13 and 3.x?
)

I think that @nafg's project (nafg/scalac-options) can do this part, but I don't know if it's the simplest interface to use at the moment as it is very detailed. It requires users to understand roughly when compiler options were added or removed from the compiler themselves in order to figure out which partial functions to write to match those options. I also worry that it might be difficult to maintain over time as the compiler output for options is not very stable. Perhaps there is a direction that we can take with that interface which makes this specific need a little easier?

Either way, I love the idea of encouraging folks to make better use of the optimizer and I love the idea of making it easier to use this plugin without having to fiddle with options right out of the box, so I look forward to hearing your ideas.

[BalmungSan]

The problem I see with your proposal is that this would imply users to select the options they want. Which, IMHO, defeats the purpose of the plugin.
I started using this plugin for three reasons:

1. To remove my long list of scalacOptions that I copied and pasted on all projects.
2. Because when 2.13 came out, my list was outdated,
3. Because it handles cross-compilation

Ideally, we should try to preserve those three properties; especially 2 & 3

I think that the best would be that the plugin provides some default sets of options that handle cross-compilation; and then a way to activate and deactivate those sets given some configurations. Also, those sets should be mutually exclusive.

This I would imagine something like this (pseudo code)

// Sets
val programmingErrors
val lintingOptions
val fatalWarnings
val warnMacrosAfter // Related to #30 & 13
val optimizations
val deault = programmingErrors || lintingOptions || fatalWarnings 

// Config
val config :=
  Config
    .builder
    .whenEnvVar(name = "CI", useSets = default)
    .whenEnvVar(name = "Release", useSets = default + optimization)
    .whenEnvVar(name = "Dev", useSets = default - fatalWarnings)

// Apply it; ideally this should be done by the plugin under the hoo.d
scalacOptions := scalacOptionsFor(scalaVersion.value, config.value)

[DavidGregory084]

The problem I see with your proposal is that this would imply users to select the options they want.

I don't see why we could not provide a default value for the dev-disabled options key. OTOH I wouldn't want to try and guess what options a user should use for their specific project to configure the optimizer. Perhaps that key could default to Seq.empty.

// Config
val config :=
  Config
    .builder
    .whenEnvVar(name = "CI", useSets = default)
    .whenEnvVar(name = "Release", useSets = default + optimization)
    .whenEnvVar(name = "Dev", useSets = default - fatalWarnings)

👍 I like this idea of providing option sets - this allows power users to do whatever they want by configuring their own option sets but leaves defaults in place for those who just want a sensible out of the box behaviour.