sbt-mima-plugin
sbt-revolver
Our great sponsors
sbt-mima-plugin | sbt-revolver | |
---|---|---|
2 | 2 | |
446 | 841 | |
0.4% | 0.2% | |
7.7 | 3.1 | |
9 days ago | 12 months ago | |
Scala | Scala | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
sbt-mima-plugin
-
Semver violations are common, better tooling is the answer
In the Scala ecosystem, MiMa [1] has been in widespread use for years. It automatically checks compatibility for the binary API of a library. Every library with any amount of success uses it. One could say it's the foundation of a stable ecosystem. We also have sbt-version-policy [2] to set it up with minimal configuration (and directly relate it to SemVer).
More recently, we got tasty-mima [3], which checks compatibility at the type system level, rather than the binary level.
[1] https://github.com/lightbend/mima
-
sbt/scalatest library or plugin that only re-runs tests for code that changed
Off the top of my head, a naive & approximate solution would be to use test coverage to find out which tests test which blocks of code. Then, when a binary, syntactic incompatibility is detected, re-run only these tests captured for that piece of code.
sbt-revolver
-
Tooling question
Another thing to look into is sbt-revolver, this will shorten the turnaround time on whatever machine is running sbt. I remember it being pretty helpful when I was working with scala.js. Good luck!
-
Friction-less scala - Tell us what is causing friction in your day-to-day life with Scala
SBT. It's not because of the pseudo-scala config language, that looks especially alien next to braceless Scala 3 code. Or the weird symbolic operators. The big problem is correctness; in almost every project I've had to use spray-resolver because I've encountered weird bugs because SBT reuses the same dirty JVM. I really thing Drip would help here. I'll keep using SBT because it has the best Scala ecosystem support and great plugins like sbt-crossproject. It would also be great to be able to write build.sbt files in modern, regular Scala.
What are some alternatives?
coursier - Pure Scala Artifact Fetching
sbt-play-scalajs - SBT plugin to use Scala.js along with any sbt-web server.
sbt-dependency-graph - sbt plugin to create a dependency graph for your project
sbt-docker - Create Docker images directly from sbt
xsbt-web-plugin - Servlet support for sbt
scala-clippy - Good advice for Scala compiler errors
sbt-scala-js-map - A Sbt plugin that configures source mapping for Scala.js projects hosted on Github
sbt-cppp - Cross-Project Protobuf Plugin for Sbt
mdoc - Typechecked markdown documentation for Scala
sbt-doctest - Doctest for scala
sbt-sonatype - A sbt plugin for publishing Scala/Java projects to the Maven central.
sbt-header - sbt-header is an sbt plugin for creating file headers, e.g. copyright headers