Feature: sort-modules in order of use

[drake-nathan]

What rule do you want to change?

sort-modules

Describe the problem

I like the idea of this rule, but I prefer to keep my code in the order that it's used. In the code example below, the rule wants to place SortJsonOptions below PrettierConfig where the interface is used. It is possible to have the rules sort in order of use first, and normally after that?

Code example

interface SortJsonOptions {
  jsonRecursiveSort?: boolean;
  jsonSortOrder?: Record<string, CategorySort | null>;
}

export type PrettierConfig = Config & SortJsonOptions;

Additional comments

No response

Validations

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.

[azat-io]

That sounds interesting. Perhaps it should be a new type of sorting. But currently I don't have any idea yet how it should work for other rules.

[hugop95]

I think that a rule like that would be almost exclusive to sort-modules. There are still a few points that I think should be investigated:

• This process exists today, but is applied to classes and enums in sort-modules, to prevent compilation/runtime issues. It is not applied to interfaces, types and functions.
• The way it works is rather simple: sorts normally, and place class/enum elements right before other elements they are dependent on: this overrides the groups system, meaning that some elements might end up "outside" of the groups they are supposed to be in.

It is possible to have the rules sort in order of use first, and normally after that?

They are two ways to approach this in my opinion:

• Keep the current system and allow the user to enable it for types/interfaces/methods. (sort alphabetically/naturally/line-length, then sort by dependencies).
• Create a new sorting type.

In both cases:

• What do we consider two elements dependent on each others?
  • How does an interface/type depend on another interface/type? Should we consider method parameter/return values?

    type ReturnType = "..."
    type Parameter = "..."
    interface Interface {
      method(param: Parameter): ReturnType;
    }

  • How does a class depend on interfaces/types?

    type ReturnType = "..."
    type Implementation = {}
    type Extension = {}
    type TypeInsideMethod = {}
    enum Enum = {}
    class Class extends Extension implements Implementation {
      property: Enum;
      method(): ReturnType {
        const a: TypeInsideMethod = "..."
      }
    }

• For interfaces/types/functions: should groups take priority over dependency-sorting?
  • Example:

   {
     groups: ["type", "interface"]
   }

  interface Interface {}
  type Type = Interface 

  What is the expected result?

[drake-nathan]

Thanks for the responses!

@hugop95 In you final example, I would expect groups to take priority unless the user has configured dependency sorting to take priority. That way, you don't have any breaking changes for the existing rule.

If I can help with this in any way, let me know!

[hugop95]

Here is a non-exhaustive list of things that we should consider before implementing anything:

• Related to Feature: sort items shared a same length after sort by line-length #429: How do you allow users to set a fallback sorting algorithm when two elements are equal?
  • This is particularly important here, as it's highly possible that a module member does not depend on anything, or that most elements depend on the same number of things, making them equal according to the dependency sorting algorithm.
• There are two types of dependencies:
  • "Hard" dependencies: if A depends on B, B must be before A for compilation or runtime behavior to be preserved: already implemented.
  • "Soft" dependencies: dependencies where the order of elements does not impact compilation nor runtime. This is opinionated and should be configurable (see What do we consider two elements dependent on each others?in the comment above)
    • How do we translate that into (hopefully readable and extendable) options that users can set ?

  • I would expect groups to take priority unless the user has configured dependency sorting to take priority

    • Same here: how do we translate that into options that users can set ?