Open armanbilge opened 2 years ago
The new plan is to use this thing:
I'd like to clarify one thing: in sbt-tpolecat there's a notion of Dev/CI/Release compiler option sets, whereas seems that sbt-typelevel does not have such a notions (with an exeption of tlFatalWaringsInCi
). Is that correct? Is there a plan to address it somehow? Or is it just fine as it is for now?
@armanbilge @DavidGregory084
@satorg Yes that's correct.
Is there a plan to address it somehow?
I don't think it's a great idea for libraries to ship artifacts compiled with different flags than what is used for CI testing, because there can be real semantic differences. So sbt-typelevel will not be adopting that notion.
See also some discussion on the issue here. https://discord.com/channels/632277896739946517/920140670394589224/1002579362316554251
We will keep the tlFatalWarnings
flag, but I've become skeptical of the tlFatalWarningsInCi
flag. See https://github.com/typelevel/sbt-typelevel/issues/254.
@isomarcte points out in https://github.com/typelevel/idna4s/pull/38#issuecomment-1281000607 that we should set default scalac options at the ThisBuild
level instead of at the project level to make them easier to customize.
Although on second thought, I'm not sure if this is possible. Determining the correct scalac options depends on knowing the scalaVersion
, and this is a project-level setting.
At the very least, I think it's a lot more organized than the sbt-typelevel-settings plugin. It's certainly more popular 😆 duplicating that effort here makes less and less sense, and there's things sbt-tpolecat gets right that are harder to fix here e.g. see https://github.com/typelevel/sbt-typelevel/pull/255.
/cc @DavidGregory084