Set up Scalafix and bump sbt-http4s-org version

[danicheg]

No description provided.

[rossabaker]

Quick, perhaps wrong, analysis: I think there was some subtlety between how Legacy Blaze had organized imports and how http4s has been doing it. That might be the cause of this.

[danicheg]

I feel that we should disable scalafix for old modules in blaze, but for some dumb reasons, I'm stuck on this. The things like

ThisBuild / scalafixAll / skip := true

just does not work.

[danicheg]

So, this is kinda funny.

> print scalafixAll / skip
> true

But

scalaFixAll --check

actually works.
This makes me mad and sad both.

[danicheg]

I'm beat almost. Now this looks like a job for Build Ninja. /cc @armanbilge 🙏🏻

[armanbilge]

Hmm, many sbt commands ignore skip unfortunately. I usually hack this in sbt-typelevel, I guess we should add scalafixAll to the list ...

Anyway, the same way we have:

• .scalafix.conf and .scalafix.test.conf
• .scalafmt.conf and .scalafmt.blaze.conf

one solution is to add a .scalafix.blaze.conf with different rule configuration, that removes the organize import rule.

[armanbilge]

Oh, an even easier solution may be .disablePlugins(ScalafixPlugin) for the relevant modules.

[danicheg]

Oh, an even easier solution may be .disablePlugins(ScalafixPlugin) for the relevant modules.

I've also tried this, this breaks the loading of sbt entirely with some plugins resolving error.

[armanbilge]

Huh, are you sure? That maybe just transient error.

[danicheg]

Hmm, many sbt commands ignore skip unfortunately. I usually hack this in sbt-typelevel, I guess we should add scalafixAll to the list ...

Anyway, the same way we have:

• .scalafix.conf and .scalafix.test.conf
• .scalafmt.conf and .scalafmt.blaze.conf

one solution is to add a .scalafix.blaze.conf with different rule configuration, that removes the organize import rule.

The idea is to disable Scalafix utterly for old modules because it brings so many changes that we do not that want now, I suppose.

[armanbilge]

I did this and it loads fine. Nope nope ignore me..... 🤯

[danicheg]

Huh, are you sure? That maybe just transient error.

sbt.AutoPluginException: error determining plugins for project 'blaze-core' in blaze/core:
Failed to sort List(sbtbuildinfo.BuildInfoPlugin, explicitdeps.ExplicitDepsPlugin, org.http4s.sbt.Http4sOrgPlugin, sbt.plugins.CorePlugin, sbt.plugins.JvmPlugin, com.typesafe.sbt.GitPlugin, org.typelevel.sbt.TypelevelScalafixPlugin, org.typelevel.sbt.TypelevelPlugin, sbt.plugins.IvyPlugin, sbt.plugins.Giter8TemplatePlugin, de.heikoseeberger.sbtheader.HeaderPlugin, org.scalafmt.sbt.ScalafmtPlugin, org.typelevel.sbt.gha.GitHubActionsPlugin, org.typelevel.sbt.TypelevelCiReleasePlugin, io.crashbox.gpg.SbtGpg, com.typesafe.tools.mima.plugin.MimaPlugin, org.portablescala.sbtplatformdeps.PlatformDepsPlugin, sbt.plugins.SemanticdbPlugin, org.typelevel.sbt.TypelevelVersioningPlugin, sbt.plugins.JUnitXmlReportPlugin, org.typelevel.sbt.TypelevelKernelPlugin, xerial.sbt.Sonatype, sbtcrossproject.CrossPlugin, com.lightbend.sbt.JavaFormatterPlugin, spray.revolver.RevolverPlugin, org.typelevel.sbt.gha.GenerativePlugin, sbt.plugins.MiniDependencyTreePlugin, org.typelevel.sbt.TypelevelSettingsPlugin, org.scalastyle.sbt.ScalastylePlugin, org.typelevel.sbt.TypelevelCiPlugin, com.lightbend.sbt.AutomateJavaFormatterPlugin, org.typelevel.sbt.TypelevelSonatypePlugin, org.typelevel.sbt.TypelevelMimaPlugin, org.typelevel.sbt.TypelevelGitHubPlugin, org.typelevel.sbt.TypelevelSonatypeCiReleasePlugin, org.typelevel.sbt.TypelevelCiSigningPlugin) topologically
	at sbt.AutoPluginException.withPrefix(Plugins.scala:138)
	at sbt.internal.Load$.translateAutoPluginException(Load.scala:999)
	at sbt.internal.Load$.finalizeProject$1(Load.scala:920)

[armanbilge]

Ok, how about this 😁

  scalafixAll := {},

Put that in commonSettings which only affect legacy blaze module.

No, also doesn't work. I think the best option is a separate config.

Edit again: huh, maybe it does work 😂

[danicheg]

D'oh 😒

[rossabaker]

Is this just about reorganizing imports in Legacy Blaze the way they're done in the rest of the org? If that's the problem, then I'm in favor of just reorganizing the imports. We don't need two sets of rules.

[danicheg]

Unfortunately, reorganizing imports is a pick of an iceberg. A huge diff, as well as unresolved conflicts (that need to be fixed with bare hands), beats us too.

[rossabaker]

Where do the conflicts arise? On the merge to main? For that, I was thinking we were probably just going to have to run scalafmt on main, and resolve conflicts as "keep ours".

[danicheg]

I meant that Scalafix run fails for some code. So it'd require us to put "scalafix:ok" properly through the codebase.

[rossabaker]

I see them now. In hindsight, should have tackled those before legacy blaze got tagged 0.23.

[danicheg]

The classic of the Computers. At local works, at CI not. (sorry for disrupting, just can't keep the pain)

[armanbilge]

You might just need to merge the latest 0.23. Also I think 04688e4 wasn't necessary, the fix in 64f09af seemed to be working fine.

[danicheg]

This branch is up to date ._. And the previous fix wasn't working at CI too.

[danicheg]

Also, the error message looks pretty weird

/home/runner/work/blaze/blaze/blaze-client/src/test/scala/org/http4s/blaze/client/BlazeClientBase.scala
[error] +++ <expected fix>
[error] @@ -20,8 +20,8 @@
[error]  import cats.effect._

it seems like the config defined for Test isn't working.

[armanbilge]

@danicheg the test config also enforces organize imports, right?

[danicheg]

Right. Then my hypothesis about Test config is wrong. But why all is good at local 🤯

[danicheg]

Although this is green at CI, I'm feeling some doubts about the correctness of Scalafix working. Nevertheless, I'm happy to win this game.

[danicheg]

And as always, thank you @armanbilge. It's cool to have you always near.

[rossabaker]

Hooray. Nice work.