sbt-mima-plugin
sbt-native-packager
Our great sponsors
| sbt-mima-plugin | sbt-native-packager | |
|---|---|---|
| 2 | 5 | |
| 447 | 1,581 | |
| 0.4% | -0.1% | |
| 7.5 | 6.8 | |
| 6 days ago | 2 days ago | |
| Scala | Scala | |
| Apache License 2.0 | BSD 2-clause "Simplified" License |
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
[2] https://github.com/scalacenter/sbt-version-policy
[3] https://github.com/scalacenter/tasty-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-native-packager
-
I had a great experience with Scala and hopefully it will get more popular
once you outgrow scala-cli, you should know sbt has a lot of plugins ( some might say it's ecosystem is the only thing keeping it relevant....) like sbt-native-packager which again does the heavy lifting for you
-
Asking for help to improve codepreview
So far, we have been working mainly with projects that use https://github.com/sbt/sbt-native-packager, still, projects building fat jars should also work smoothly.
-
I removed sbt-assembly and sbt-buildinfo from my project.
You should use sbt-jib. (You shouldn't use sbt-native-packager either, it doesn't work well in this regard: [1], [2].)
-
Why Scala is way slower than python ... and than Java too in leetcode?
As others have stated, this is mainly due to the nature of the JVM. You can try using GraalVM however, which basically complies JVM bytecode to native-code avoiding startup time issues, sbt-native-packager lets you do this quite easily.
-
SBT error when running package application: java.lang.RuntimeException: No main class detected.
IMO don't take any of this advice and use https://github.com/sbt/sbt-native-packager
What are some alternatives?
mdoc - Typechecked markdown documentation for Scala
sbt-assembly - Deploy über-JARs. Restart processes. (port of codahale/assembly-sbt)
sbt-header - sbt-header is an sbt plugin for creating file headers, e.g. copyright headers
sbt-pack - A sbt plugin for creating distributable Scala packages.
sbt-revolver - An SBT plugin for dangerously fast development turnaround in Scala
coursier - Pure Scala Artifact Fetching
sbt-native-image - Plugin to generate native-image binaries with sbt
sbt-updates - sbt plugin that can check Maven and Ivy repositories for dependency updates
xsbt-web-plugin - Servlet support for sbt
sbt-sonatype - A sbt plugin for publishing Scala/Java projects to the Maven central.
sbt-release - A release plugin for sbt