Conflicting line length rule with scalafmt
See original GitHub issueSo far this plugin works really nice 🙂 . I only encountered the following issue. I have an import statement as follows:
import sttp.client.{
DeserializationError,
HttpError,
NothingT,
Response,
ResponseAs,
ResponseError,
SttpBackend,
basicRequest
}
scalafix-organize-imports tries to rewrite it to
import sttp.client.{DeserializationError, HttpError, NothingT, Response, ResponseAs, ResponseError, SttpBackend, basicRequest}
while scalafmt insists on the original formatting. My .scalafmt.conf
:
version = "2.4.1"
align = more
maxColumn = 100
rewrite {
rules = [
SortModifiers,
RedundantBraces,
PreferCurlyFors
]
redundantBraces.stringInterpolation = true
}
and .scalafix.conf
:
rules = [
NoAutoTupling,
DisableSyntax,
LeakingImplicitClassVal,
NoValInForComprehension,
ProcedureSyntax,
OrganizeImports
]
OrganizeImports {
groupedImports = Merge
}
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (5 by maintainers)
Top Results From Across the Web
Configuration · Scalafmt - Scalameta
The difference is, the rule forces a newline before a matching assignment expression whether or not it can be formatted on a single...
Read more >scalameta/scalafmt - Gitter
Hi everyone, is it possible to avoid ever splitting up the single argument of a method call on its own line? Especially, if...
Read more >scalafmt: opinionated code formatter for Scala
Many coding styles enforce a maximum line length to ensure code is readable from different environments such as small split screens and code ......
Read more >sbt Reference Manual — Combined Pages
If you have any trouble running sbt, see Command line reference on JVM options. ... Once those targets are created using the last...
Read more >Code formatting: scalafmt and the git pre-commit hook - Medium
It can be run from the command line or as sbt task — making sure ... All you need to do is decide...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Excellent! Indeed the issue is resolved with 0.3.0+5-98c374f1-SNAPSHOT 😃
@arjun-1, thank you so much for the minimal reproduction! I figured out why it didn’t work for you. It’s because you are using Scala 2.13 while
OrganizeImports
is built using Scala 2.12.OrganizeImports
callsimporter.syntax
to pretty-print an import expression. Internally, thesyntax
method accepts an implicitscala.meta.Dialect
parameter. While pretty-printing, thesyntax
method checks two things:When both conditions are true, it simply returns the original source text being parsed. Otherwise, it pretty-prints the AST node using the implicit dialect.
OrganizeImports
is built using Scala 2.12, so at runtime, this implicit dialect is by default Scala 2.12. Therefore, condition 2 doesn’t hold.Instead, we can simply replace the
importer.syntax
withimporter.toString
. The latter doesn’t check condition 2. So it always returns the original source text if an import originates from the parser. In other cases, it always uses Scala 2.11 dialect, which is also good enough for pretty-printing import statements.