Scala SBT

Open-source Scala projects categorized as SBT | Edit details

Top 23 Scala SBT Projects

  • GitHub repo sbt

    sbt, the interactive build tool

    Project mention: SBT management on Apple M1 | | 2021-04-30

    It's an issue with the zule jvm and Java native access. A workaround is provided in this thread.

  • GitHub repo sbt-assembly

    Deploy über-JARs. Restart processes. (port of codahale/assembly-sbt)

    Project mention: SBT error when running package application: java.lang.RuntimeException: No main class detected. | | 2021-06-09

    You may also use sbt-assembly to produce an uber JAR that embeds the Scala stdlib together with your code, which means that now for running your program you only need a JRE like java -jar app-assembly.jar. This option is great because now if you start adding dependencies to your project those are also included in this massive JAR.

  • Scout APM

    Scout APM: A developer's best friend. Try free for 14-days. Scout APM uses tracing logic that ties bottlenecks to source code so you know the exact line of code causing performance issues and can get back to building a great product faster.

  • GitHub repo sbt-native-packager

    sbt Native Packager

    Project mention: Why Scala is way slower than python ... and than Java too in leetcode? | | 2021-07-15

    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.

  • GitHub repo scala-steward

    :robot: A bot that helps you keep your Scala projects up-to-date

    Project mention: Scala projects to read through | | 2021-08-07
  • GitHub repo Scala-Logging

    Convenient and performant logging library for Scala wrapping SLF4J. (by lightbend)

  • GitHub repo sbt-docker

    Create Docker images directly from sbt

  • GitHub repo sbt-updates

    sbt plugin that can check Maven and Ivy repositories for dependency updates

  • Nanos

    Run Linux Software Faster and Safer than Linux with Unikernels.

  • GitHub repo Scalafix

    Refactoring and linting tool for Scala

    Project mention: Newspeak and Domain Modeling | | 2021-06-29

    or `NonUnitStatements` without explicit annotation.

    This effectively locks you into writing pure code (you can extend the linter to cover other things like not using `Future` or not using Java libs outside of `MonadError` from cats[4]). The linters operate on typed ASTs at compile time, and have plugins for the most popular scala build tools. Coupled with `-XFatalWarnings', you can guarantee that nothing unexpected happens unless you explicitly pop the escape hatch, for the most part.

    You can still bring in external libraries that haven't been compiled with these safties in place, so you aren't completely safe, but if you use ZIO[5]/Typelevel[6] libraries you can be reasonably assured of referentially transparent code in practice.

    There are three schools of thought, roughly, in the scala community towards the depth of using the type system and linters to provide guarantees and capabilities, currently:

    1) Don't attempt to do this, it makes the barrier to entry to high for Scala juniors. I don't understand this argument - you want to allow runtime footguns you could easily prevent at compile time because the verifiable techniques take time to learn? Why did you even choose to use a typesafe language and pay the compilation time penalty that comes with it?

    2) Abstract everything to the smallest possible dependency interface, including effects (code to an effect runtime, F[_] that implements the methods your code needs to run - if you handle errors, F implements MonadError, if you output do concurrent things, F implements Concurrent, etc.) and you extend the effect with your own services using tagless final or free.

    3) You still use effect wrappers, but you bind the whole project always to use a concrete effect type, avoiding event abstraction, thus making it easier to code, and limiting footguns to a very particular subset (mainly threadpool providers and unsafeRun or equivalent being called eagerly in the internals of applications).

    My opinion is that smallest interface with effect guarantees (#2) is best for very large, long maintenance window apps where thechoice of effect runtime might change(app), or is out of the devs' control (lib); and #3 is best for small apps.

    TL/DR; You can go a really, really long way to guaranteeing effects don't run in user code in scala. Not all the way like Haskell, but far enough that it's painful to code without conforming to referential transparency.







  • GitHub repo sbt-release

    A release plugin for sbt

  • GitHub repo sbt-buildinfo

    I know this because build.sbt knows this.

  • GitHub repo OutWatch

    The Functional and Reactive Web-Frontend Library for ScalaJS

  • GitHub repo xsbt-web-plugin

    Servlet support for sbt

  • GitHub repo ScalNet

    A Scala wrapper for Deeplearning4j, inspired by Keras. Scala + DL + Spark + GPUs

  • GitHub repo scastie

    An interactive playground for Scala

    Project mention: Scala or Go: Who Wore It Better? | | 2021-09-06

    Operationally, as you might expect from a language borne from academia, Scala tooling can be problematic and compilation can be slow--particularly if you are not yet using Scala 3, which only recently emerged and is very slowly percolating through the ecosystem (Remember the Python 2 to Python 3 transition?). But type inference, a vast standard library, and the time-tested reliability of the JVM make you very productive once you get the hang of them. Performance varies with the JVM you're running, but regardless you do have to contend with the size of compiled objects and the latency of garbage collection at runtime. When you want to experiment, you can skip the ceremony of writing a class or test and instead use a command-line REPL, an online REPL called Scastie you can share, or an outstanding third-party command-line REPL called Ammonite. Dependency management is achieved with SBT typically but also more general JVM build tools like Gradle and Maven.

  • GitHub repo sbt-microsites

    An sbt plugin to create awesome microsites for your project

    Project mention: Friction-less scala - Tell us what is causing friction in your day-to-day life with Scala | | 2021-08-10
  • GitHub repo scala3-example-project

    An example sbt project that compiles using Dotty

    Project mention: What are resources to learn/get up to speed with Scala3 for experienced Scala2 dev? | | 2021-06-06
  • GitHub repo sbt-tpolecat

    scalac options for the enlightened

    Project mention: Is there a way to beautify the code after Scala 3 migration? | | 2021-08-24

    Sorry, have nothing useful to contribute (although I'd recommend you to set a restrictive set of scalac flags, for example from sbt-tpolecat, to let compiler help you), but just wanted to praise the Scala team and remind us of all those "Python 3 situation" rants we've saw 2 years ago and how silly they look now.

  • GitHub repo sbt-dependency-check

    SBT Plugin for OWASP DependencyCheck. Monitor your dependencies and report if there are any publicly known vulnerabilities (e.g. CVEs). :rainbow:

    Project mention: Security Vulnerability Scanning for Scala | | 2021-05-23
  • GitHub repo sbt-play-scalajs

    SBT plugin to use Scala.js along with any sbt-web server.

  • GitHub repo sbt-crossproject

    Cross-platform compilation support for sbt.

    Project mention: Friction-less scala - Tell us what is causing friction in your day-to-day life with Scala | | 2021-08-10

    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.

  • GitHub repo sbt-doctest

    Doctest for scala

  • GitHub repo sbt-site

    Site generation for sbt

  • GitHub repo sbt-native-image

    Plugin to generate native-image binaries with sbt

    Project mention: Native Image Compilation for A Purely Functional Example Application | | 2021-08-15

    IIRC, the sbt-native-image plugin can abstract that away, too:

NOTE: The open source projects on this list are ordered by number of github stars. The number of mentions indicates repo mentiontions in the last 12 Months or since we started tracking (Dec 2020). The latest post mention was on 2021-09-06.


What are some of the best open-source SBT projects in Scala? This list will help you:

Project Stars
1 sbt 4,376
2 sbt-assembly 1,771
3 sbt-native-packager 1,467
4 scala-steward 892
5 Scala-Logging 832
6 sbt-docker 701
7 sbt-updates 674
8 Scalafix 635
9 sbt-release 591
10 sbt-buildinfo 494
11 OutWatch 383
12 xsbt-web-plugin 382
13 ScalNet 343
14 scastie 339
15 sbt-microsites 297
16 scala3-example-project 291
17 sbt-tpolecat 252
18 sbt-dependency-check 205
19 sbt-play-scalajs 185
20 sbt-crossproject 184
21 sbt-doctest 180
22 sbt-site 167
23 sbt-native-image 166
Find remote jobs at our new job board There are 25 new remote jobs listed recently.
Are you hiring? Post a new remote job listing for free.
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives