Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default dialect for Scala version specific directory #2882

Closed
exoego opened this issue Nov 10, 2021 · 5 comments · Fixed by #2902
Closed

Default dialect for Scala version specific directory #2882

exoego opened this issue Nov 10, 2021 · 5 comments · Fixed by #2902

Comments

@exoego
Copy link

exoego commented Nov 10, 2021

As a maintainer for several cross-built libraries , it is painful to configure dialect explicitly for Scala version specific source directories like below:

fileOverride {
  "glob:**/src/**/scala-3/**" {
    runner.dialect = scala3
  }
  "glob:**/src/**/scala-2.13/**" {
    runner.dialect = scala213
  }
  "glob:**/src/**/scala-2.12/**" {
    runner.dialect = scala212
  }
}

It would be helpful if scalafmt assume dialect for each version specific directories automatically.

@xerial
Copy link

xerial commented Nov 10, 2021

And also, sbt now adds scala-2 (epoch directory) source folder by default. sbt/sbt#5919
Should we add this setting as well?

  "glob:**/src/**/scala-2/**" {
    runner.dialect = scala213
  }

@kitbellew
Copy link
Collaborator

and when you dialect-specific directories, which dialect should be used for the usual scala directory? or for scala-2 mentioned above?

@kitbellew
Copy link
Collaborator

As a maintainer for several cross-built libraries , it is painful to configure dialect explicitly for Scala version specific source directories like below:

i think it's inconvenient. painful was when there was no fileOverride option.

on your request, can you suggest a way? since scalafmt doesn't know which build system is used, it can't really tell which modules are being built, and whether scala-2.13 is the name of some directory above source code.

sbt-scalafmt might be able to do that, for sbt builds.

@exoego
Copy link
Author

exoego commented Nov 11, 2021

i think it's inconvenient. painful was when there was no fileOverride option.

That's right. "Painful" was inappropriate in this context 😅
fileOverride is great, and could be greater if this inconvenience is addressed.

scalafmt doesn't know which build system is used, it can't really tell which modules are being built, and whether scala-2.13 is the name of some directory above source code.

Ah, sorry, I did not consider how scalafmt interacts with build system.
Actually, I use sbt to build all projects.
So enhancement in sbt-scalafmt rather scalafmt-core is fine for me.

can you suggest a way?

I imagine that sbt-scalafmt...

  1. receives a path to ~~~.scala file.
  2. if the path matches any entries in fileOverride, then use that dialect and end.
  3. else if the path includes scala-2.13 or similar, and does not match any entries in fileOverride, then assume dialect and end.
  4. otherwise, use the top-level specifieddialect.

which dialect should be used for the usual scala directory?

I think the top-level dialect should be used for the usual scala directory.

or for scala-2 mentioned above?

Ah, it is good question.
Perhaps the latest scala213, or no automatic dialect for scala-2 and uses the top-level dialect.

@kitbellew
Copy link
Collaborator

kitbellew commented Nov 11, 2021

  1. else if the path includes scala-2.13 or similar, and does not match any entries in fileOverride, then assume dialect and end.

and what should we do if the directory structure is src/no/scala-2.13/here/src/main/scala/...? you can use "glob:**/src/**/scala-2.13/**" but in scalafmt we can't make such a general assumption.

Ah, it is good question. Perhaps the latest scala213, or no automatic dialect for scala-2 and uses the top-level dialect.

ok, and if you have both scala-2 and scala-3? now we need to have a default dialect for scala2 and separately a default dialect for scala3 (and, as @soronpo mentioned on gitter, a default dialect for sbt). and if we have to specify them explicitly, then using fileOverride is simply slightly longer than a trivial one-liner but not by much and not subject to any mistakes.

if you have many cross-built projects, quite simple to copy-paste once...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants