Metals: Organize imports

[pmellati]

Is your feature request related to a problem? Please describe.

The editor doesn't help with organizing my imports. Also, when the editor automatically adds an import, it doesn't insert at the right location.

Describe the solution you'd like

• Add a new setting that allows the user to describe a strategy for organizing imports. Should be flexible enough to express:
  
  
  
  • The grouping of imports, and order of groups (e.g. scala std-lib imports first, java imports next, third party imports next, imports from current project last)
  
  
  • The ordering of imports within groups (e.g. alphabetical)
  
  
  • How wildcard imports should be used (e.g. if more than 6 imports from the same package, use a wildcard.)
  
  
• Add an operation to "organize imports" at will.
• If the imports (in the current file) are already organized, and the editor is adding a new import statement automatically, the new import should be added so that the imports remain organized.

Describe alternatives you've considered

Additional context

Search terms:

optimize imports

[Daenyth]

An addition to this request: It should be possible to have a project-level config file which can be committed to a source repo which instructs metals as to what organizing strategy to use, so that each person's editor uses the same structure

[rkrzewski]

For the record, in the discussions on gitter, multiple people suggested that if this feature was implemented in scalafmt, not only Metals but also other tools would benefit from it.

[mwz]

@NeQuissimus has implemented a Scalafix rule for organising imports (https://github.com/NeQuissimus/sort-imports), perhaps it could be integrated with metals once Scalafix actions are supported as a part of scalameta/metals#1675?

[rkrzewski]

@mwz Metals already supports running scalafmt on demand / on save, and scalafmt has a configuration file that could hold import organization preferences.

I'm not familiar with scalafix / scalafmt internals, but since both are based on scalameta, my guess is that porting the code shouldn't be too hard - seems like a good first step to support this feature.

As for the next step, it probably would be good to reverse engineer import organization options in IntelliJ and reimplement them to accommodate teams using mixed tolling.

[gabro]

@rkrzewski the issue with Scalafmt is that it's purely syntactical, but organizing imports may potentially change the semantics of the code due to shadowing.

That's why Scalafix is a preferred option: it has an API that allows to write a semantically safe rewrite (although it's not an easy task)

The linked Scalafix rule linked above is purely syntactical, but that's a limitation of the specific rule, not of the tool.

[Daenyth]

As for the next step, it probably would be good to reverse engineer import organization options in IntelliJ and reimplement them to accommodate teams using mixed tolling.

It's open source (Apache 2)

https://github.com/JetBrains/intellij-scala/tree/idea193.x/scala/scala-impl/src/org/jetbrains/plugins/scala/editor/importOptimizer

[olafurpg]

Small update, @liancheng has created an OrganizeImports Scalafix rule that does a great job of organizing imports from what I have seen so far (example diff on the Metals codebase https://github.com/scalameta/metals/pull/1646).

This unblocks the biggest issue for adding support for "organize imports" in Metals: implementing the actual "organize imports" logic :) The remaining issue is to add a Scalafix integration https://github.com/scalameta/metals-feature-requests/issues/7

[gabro]

To clarify, the only thing that's still missing from the original feature request is that auto-imports won't automatically follow the configured grouping. The user still needs to run the organize import command manually. (Correct me if I'm wrong @mlachkar, @tgodzik)

Still, the main functionality is there (integrated in the editor, configurable via .scalafix.conf, etc)! I personally think the current UX is good enough, but if somebody cares about the auto-import thing, I suggest to open a smaller dedicated feature request for it

[tgodzik]

@gabro Yeah, auto import will not work. I think that might be done once we manage to run organize imports on unsaved files. We could apply edits internally and run the sort on it. That's just one idea, but might hard to do. The other option would be to duplicate the logic from organize imports rules, but I would rather not go into that direction.

[gabro]

@tgodzik if we manage to run organize imports on unsaved filed (or rather, "just saved" files which have no semanticdb produced by batch compilation yet), then I think we should treat organize imports the same as formatting (i.e. something to ran automatically on save)

I would recommend setting up the editor so that organize imports is ran on save, which in VSCode can be done with

  "[scala]": {
    "editor.codeActionsOnSave": {
      "source.organizeImports": true
    }
  },

(This is currently not viable because organize imports cannot be ran right after saving, since it needs for compilation to happen first)