Scalafix
sbt
Our great sponsors
Scalafix | sbt | |
---|---|---|
6 | 20 | |
801 | 4,753 | |
0.5% | 0.3% | |
9.2 | 9.1 | |
5 days ago | 6 days ago | |
Scala | Scala | |
BSD 3-clause "New" or "Revised" License | 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.
Scalafix
-
Security static analysis tooling for Scala?
I also recommend using Scalafix. It's a tool which can lint your codebase, checking for potentially problematic things, like
-
Which static analysis tool do you use for Scala?
Scalafix
-
Dragging Haskell Kicking and Screaming into the Century of the Fruitbat :: Reasonably Polymorphic
scala-fix seems relevant for the /= removal problem.
-
Newspeak and Domain Modeling
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.
1. https://github.com/scalacenter/scalafix
2. https://github.com/scalaz/scalazzi
3. http://www.wartremover.org/
4. https://typelevel.org/cats/api/cats/MonadError.html
5. https://zio.dev/
6. https://typelevel.org/
-
Scala noob question. Parameter of type Option. Why does scala compiler allows passing null as an argument?
I actually still recommend using WartRemover, at least until there's an equivalent ScalaFix ruleset that's as effective.
-
Teaching exercises with custom error messages
Probably linting rules defined in Scalafix. See https://github.com/scalacenter/scalafix/blob/master/scalafix-rules/src/main/scala/scalafix/internal/rule/DisableSyntax.scala#L11 for an example.
sbt
-
Declarative Gradle is a cool thing I am afraid of: Maven strikes back
NOTE: I won’t mention SBT and Leiningen here because, with all due respect, they are niche build tools. I also won’t discuss Kobalt for the same reason (besides, it’s no longer actively maintained). Additionally, I won’t touch upon Bazel and Buck in this context, mainly because I’m not very familiar with them. If you have insights or comments about these tools, please feel free to share them in the comments 👇
-
Øyvind Berg and John De Goes discuss Bleep, the new config-as-data build tool
Sbt has the primitives that would allow that, but this would change the semantics of the test task. See also testQuick and https://github.com/sbt/sbt/issues/6292
-
Scala Center Roadmap for 2023 and Beyond
If I use IntelliJ then apparently sbtn is not supported and they don't bother with Scala-CLI or Coursier.
-
The size of sbt became big
Version 1.3.13 has a size of 1.17 MB in zip
-
sbt 1.8.0 released
See scala-xml 2.x mega tracker on plugin ecosystem conflicts.
-
sbt 1.7.3 released
This is under discussion at https://github.com/sbt/sbt/issues/6997
-
Make your zip packages for lambdas (and many more use cases) idempotent with a zip-drop-in replacement
See https://github.com/playframework/playframework/issues/10572 and https://github.com/sbt/sbt/issues/6235 for more details and context.
-
How do i stop git bash from showing the time taken for each command
BTW, if you're curious, it appears OP is using this: https://github.com/sbt/sbt/releases/tag/v1.6.2 Pretty sure one of the executables is doing ANSI colours.
-
simplifying sbt with common settings
If you see the progression of documentation changes over the years pushing people towards multi-project style, and issues like https://github.com/sbt/sbt/issues/6217, hopefully you'd see that I've really tried to encourage people to use multi-project style from the get go.
-
sbt 1.5.7 released
Fyi in case anyone is curious, sbt is fully removing log4j going forward: https://github.com/sbt/sbt/pull/6726
What are some alternatives?
scalafmt - This repo is now a fork of --->
Mill - Your shiny new Java/Scala build tool!
Scalastyle - scalastyle
dotty - The Scala 3 compiler, also known as Dotty.
Wartremover - Flexible Scala code linting tool
bloop - Bloop is a build server and CLI tool to compile, test and run Scala fast from any editor or build tool.
Scapegoat - Scala compiler plugin for static code analysis
scala-3-migration-guide - The Scala 3 migration guide for everyone.
Metals - Scala language server with rich IDE features 🚀
sonar-scala - A free and open-source SonarQube plugin for static code analysis of Scala projects.