Bug: `destructuredObjects: { groups: true }` doesn't respect groups in `perfectionist/sort-objects`

[hikack]

Describe the bug

Even though the sorting is respecting the groups on objects, but on the destructured objects, it doesn't respect that
the rule config:

    "perfectionist/sort-objects": [
      "error",
      {
        type: "line-length",
        order: "asc",
        fallbackSort: { type: "natural", order: "asc" },
        partitionByNewLine: true,
        groups: [
          "property",
          "multiline-property",
          "method",
          "multiline-method",
          "unknown",
        ],
        destructuredObjects: { groups: true },
      },
    ],

Code example

what it should acts:

const sampleObject = {
  property1: "value1",
  property2: "value2",
  method1: () => "result1",
  method2: () => "result2",
};

const { property1, property2, method1, method2 } = sampleObject;

but the actuall result is:

const sampleObject = {
  property1: "value1",
  property2: "value2",
  method1: () => "result1",
  method2: () => "result2",
};

const { method1, method2, property1, property2 } = sampleObject;

ESLint version

8.57.1

ESLint Plugin Perfectionist version

4.13.0

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.

[hugop95]

Hi @hikack ,

We can't infer that method1 and method2 are functions in the destructured object. This is unfortunately a technical limitation with the plugin at the moment.

[hikack]

Hey @hugop95 ,
Is it possible to do so? For example, the way methods and properties are colored differently in VS Code. Hopefully, we can support this feature. if you give me more context, maybe I can dedicate some time to it and create a PR for that

[hugop95]

@hikack

Is it possible to do so? For example, the way methods and properties are colored differently in VS Code. Hopefully, we can support this feature. if you give me more context, maybe I can dedicate some time to it and create a PR for that

It is something that I've wanted to investigate deeper since a while (for example in #409 (comment)).

We would need to start using typescript-eslint's parser service and keep track/correctly infer the types of deconstructed properties.

I did a couple of quick tests months ago and the conclusion was that it's likely possible. The question is: at what cost?

• We would need to see if we can benefit from adding the parser service for other rules.
• It's likely that the large majority of use cases for this rule (sort-objects) don't require using the parser service, so who knows if it's interesting going further just for this rule.
  • Additionally, we should make sure that performance is not impacted for the current uses cases that don't require the parser services.

Long story short: it's not a small addition, and there is clearly quite a lot of investigation to do. Feel free to experiment if you wish 🙂