I would like to disable source maps generation for fullOptJS (production mode).
It is not always appropriate to have all the information about original Scala source files.
I didn't find any suitable options to disable output entirely or something similar?
Is there any link to the documentation with all the options available for scalajs sbt plugin?
Thanks for any help
The sbt setting scalaJSLinkerConfig, of type StandardLinker.Config, contains all the options you can possibly give to the Scala.js linker, i.e., the thing that optimizes everything and emits a .js file. For some reason, Scaladoc refuses to display the comments on of the vals, although they exist in the source code.
You can see there a val sourceMap: Boolean, which clearly configures whether the linker is going to emit source maps. You can set it to false in fullOptJS with the following sbt incantation, to be placed in the .settings(...) of the relevant project:
scalaJSLinkerConfig in (Compile, fullOptJS) ~= { _.withSourceMap(false) }
(see also this answer about what ~= means in sbt)
Related
It often comes up during testing and debugging a Scala project built with sbt that I need to pass some extra compiler flags for a particular file. For example -Xlog-implicits to debug implicit resolution problems. However, changing scalacOptions either in build.sbt or the console invalidates the cache and causes the whole project / test suite to be recompiled. In addition to being annoying to wait so long, this also means that a lot of noise from irrelevant files is printed. Instead it would be better if I could compile a specific file with some extra flags from the sbt console, but I did not find a way to do this.
Problem
The reason why changing the scalac options triggers recompilation is because Zinc, Scala's incremental compiler, cannot possibly now which compiler flags affect the semantics of the incremental compilation, so it's pessimistic about it. I believe this can be improved, and some whitelisted flags can be supported, so that next time people like you don't have to ask about it.
Nevertheless, there's a solution to this problem and it's more generic than it looks like at first sight.
Solution
You can create a subproject in your sbt build which is a copy of the project you want to "log implicits" in, but with -Xlog-implicits enabled by default.
// Let's say foo is your project definition
lazy val foo = project.settings(???)
// You define the copy of your project like this
lazy val foo-implicits = foo
.copy(id = "foo-implicits")
.settings(
target := baseDirectory.value./("another-target"),
scalacOptions += "-Xlog-implicits"
)
Note the following properties of this code snippet:
We redefine the project ID because when we reuse a project definition the ID is still the same as the previous one (foo in this case). Sbt fails when there are projects that share the same id.
We redefine the target directory because we want to avoid recompilation. If we keep the same as before, then recompiling foo-implicits will delete the compilation products of the previous compilation (and viceversa). That's exactly what we want to avoid.
We add -Xlog-implicits to the Scalac options as you request in this question. In a generic solution, this piece of code should go away.
When is this useful?
This is useful not only for your use case, but when you want to have different modules of the same project in different Scala versions. The following has two benefits:
You don't use cross-compilation in sbt ++, which is known to have some memory issues.
You can add new library dependencies that only exist for a concrete Scala version.
It has more applications, but I hope this addresses your question.
I'd like to be able to turn off a particular compiler warning, but only for a single file in my project. Is this possible?
The context is that I have a single source file that makes calls to an external macro library that produces adapted-arg warnings. I found that I can eliminate these warnings by changing my build.sbt file:
scalacOptions ++= Seq("-Xlint:-adapted-args,_" /*, ... */)
However, this turns off the warning globally, and I only want it off for the single file that raises them.
I haven't had any luck searching for any of the following possible solutions I thought might exist:
Specifying separate compilation options for different files in my project in my build.sbt file
Providing some pragma-like comment in my source file to change the warnings generated by the compiler, similar to the special scalastyle:on/off comments recognized by Scalastyle
Some annotation for smaller regions of code, like #unchecked
So, is there any way to have different linting options in effect for different files, or even for limited regions of code?
The expectation was that folks would write a custom Reporter that would filter out undesirable warnings.
It's easy to write one that filters by file name, perhaps given a whitelist.
The error/warn API supplies the textual Position. It would also be easy to parse the position.lineContent for a magic comment token like IGNORE or SUPPRESS, which is not as convenient as a SuppressWarnings annotation but is easy to implement.
The compiler asks the reporter if there were errors.
The custom reporter is specified with -Xreporter myclass, or it wouldn't surprise me if someone has written an sbt plugin.
I am using play framework v2.3. The problem I am facing is that any change in html and refreshing browser causes recompilation of the complete code. Can I avoid this?
Twirl templates are compiled, as stated by the docs:
Templates are compiled as standard Scala functions, following a simple naming convention. If you create a views/Application/index.scala.html template file, it will generate a views.html.Application.index class that has an apply() method.
There is no way to disable this behavior because it works this way by design. My suggestion here is use ~ (tilde) before SBT commands so things will happen as you save the file, per instance:
sbt ~run
This will recompile the changed file (and possible others), every time you change and save it. Also, sbt has some options that can possibly help you here: withNameHashing.
See sbt docs to understand how it works. To enable it, add the following line to your build.sbt file:
incOptions := incOptions.value.withNameHashing(nameHashing = true)
I've added the -Xlinter and -Ywarn-unused-import scalac flags to a project of mine. The problem is that I'm using a source generator and it creates code that doesn't pass all the checks - there are dead code and unused import warnings. Is there a way for me to have a different set of scalacOptions for managed vs. unmanaged code?
I'll copy what Seth answered in comment section.
Using subprojects is the right way to go about this.
I'm using sbt 0.11.2 for a mixed Java/Scala project. I've realized that when I run the doc command from within sbt, it does not only create the scaladocs for the Scala source files in src/main/scala, but also for the Java source files in src/main/java (the sbt wiki claims to create them for src/main/scala only that seems not true).
However, this does not look very well. For instance, for a Java class named Foo with static methods there are two entries in the generated scaladoc: a Foo class and a Foo object. The class only lists the constructor and the object lists the static methods.
Is there any way I can tell sbt to exclude the src/main/java folder from the scaladoc generation? I want to create javadocs for those instead.
The usual way to handle that is to use inspect to see where the information is coming from, and then change it. Inspecting at doc shows compile:sources(for doc), which is a Seq[java.io.File], and can be changed like this:
sources in (Compile, doc) ~= (_ filter (_.getName endsWith ".scala"))
You can use show compile:sources(for doc) to see what it contains, and then set to change it and check again its value.