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

Add a concept of "root" package/s #1792

Closed
mdedetrich opened this issue Jun 17, 2023 · 1 comment
Closed

Add a concept of "root" package/s #1792

mdedetrich opened this issue Jun 17, 2023 · 1 comment

Comments

@mdedetrich
Copy link
Contributor

This issue is about creating the concept of a "root" package. The definition of a root package is one where all other packages are nested under it? As an example in Pekko we would have org.apache.pekko as a "root" package since all scala code placed under org.apache.root.

Such a concept is useful primarily for reducing code boilerplate, i.e. this pattern is already being used in Pekko (see https://github.com/apache/incubator-pekko/blob/1612950702d4dc8107f336442c7617cc67e22eda/remote/src/main/scala/org/apache/pekko/remote/FailureDetectorRegistry.scala as an example) because otherwise would literally have cases where when referring to a type/class/import etc etc if we used the fully qualified name, that byitself would just take up half the screen.

The premise of the issue is to create a concept of root packages, i.e. in your .scalafix.conf you would have something like this

root-packages = [
  "org.apache.pekko",
  "org.apache.kafka"
]

And then other rules/rewrites would use that if relevant/necessary. So far the main rule that I can think of where this is relevant is OrganizeImports and there is already a ticket on this at liancheng/scalafix-organize-imports#312 but there may be some cases which I am missing.

@bjaglin
Copy link
Collaborator

bjaglin commented Jul 19, 2023

Thanks for the detailled report(s) @mdedetrich!

Since .scalafix.conf is parsed as HOCON (through metaconfig), any block that is meant to be repeated can be declared in an arbitrary key and referenced wherever needed, as showcased here.

As a result, I will close this as it seems good enough to handle your (speculated) use-case, without the need to introduce a new paradigm for configuring rules. Let's focus on the OrganizeImports use case.

@bjaglin bjaglin closed this as completed Jul 19, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants