Feature: Support ignoring objects by variable name in sort-objects

[Gajdascz]

What rule do you want to change?

sort-objects

Describe the problem

Currently, there does not seem to be a way to ignore objects by variable name when using sort-objects. This makes working with order-dependent objects difficult.

Code example

In oclif the args object is order-dependent. Sorting it ruins the positional input.

import { Command, Args } from '@oclif/core';

/**
 * The order of args is always intentional and should not be sorted.
 */
export default class MyCommand extends Command {
  static override args = {
    type: Args.string({
      name: 'type',
      options: [type1,type2,type3],
      required: true
    }),
    description: Args.string({
      name: 'description',
      required: true
    }),
    scope: Args.string({
      name: 'scope',
      required: false
    })
  }
}

Additional comments

This deprecated rule seems to state it's possible to ignore objects by it's name. But I was not able to get it to work and regardless it's deprecated.

• https://perfectionist.dev/rules/sort-objects#deprecated-ignorepattern

The alternative to the deprecated rule according to the docs is useConfigurationIf with unsorted type. But its two rules allNamesMatchPattern and callingFunctionNamePattern don't solve this issue. allNamesMatchPattern only matches object keys and I'm not using functions in this context.

• https://perfectionist.dev/rules/sort-objects#useconfigurationif

Validations

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

[azat-io]

Please tell me how common this case is and why using eslint-disable comments is not appropriate?

[Gajdascz]

I cannot speak to how common this is across all projects, but in CLI packages like those built with oclif, order-dependent objects (e.g., the args object) are non-negotiable. Sorting them breaks intended positional behavior, so workarounds are otherwise required.

Using eslint-disable comments is not ideal because, aside from being a perfectionist, they introduce repetitive, local escape hatches. This can make it harder to maintain consistent rules across multiple order-dependent objects and can allow subtle bugs to go unnoticed if a comment is missed. For nested objects, the problem compounds, as every child requires its own disable comment.

[hugop95]

It indeed looks like ignorePattern is not fully replaced by useConfigurationIf options: it doesn't target variable declarations. Adding a useConfigurationIf.declarationMatchesPattern option should be simple and fully allow use to deprecate ignorePattern.

[noobfromvn99]

Hi, I just ran into this issue as well. I would love to get declarationMatchesPattern added to useConfigurationIf.

I would like to skip sorting all object by the name of the object. For me I am using Sequelize package and it is important to not sort object with the name where so it would pick up database index correctly.

[hugop95]

Overall, I think that there can be 3 use cases for this feature:

Case 1: Ignore an object if its constant/variable declaration matches a pattern.

const ignoreMe = {
  b,
  a
}

➡️ ❌ Only supported by deprecated ignorePattern today.

Case 2: Ignore an object if its object attribute name matches a pattern.

{
 ignoreMe: {
   b,
   a
 }
}

Or

{
  ignoreMe() {
    return {
      b,
      a
    }
  }
}

➡️ ❌ Only supported by deprecated ignorePattern today.

Case 3: Ignore an object if its function caller's name matches a pattern.

const you.shouldIgnoreMe(..., {
  b,
  a
}

➡️ ✅ useConfigurationIf.callingFunctionNamePattern today.

---

Additionally, for each of those use cases, there can be 2 ways to match an object.

Apply the condition to nested objects

const ignoreMe = {
  aNestedObject: {
    b,
    a
  }
}

➡️ This is the behavior of ignorePattern.

Do not apply the condition to nested objects

const dontIgnoreMe = {
  aNestedObject: {
    a,
    b
  }
}

➡️ This is the behavior of useConfigurationIf.callingFunctionNamePattern.

---

Proposal

• Rename useConfigurationIf.callingFunctionNamePattern: string ➡️ useConfigurationIf.callingFunctionName: { pattern?: string, scope?: "shallow" | "deep"}
  • If scope is not entered, take shallow by default.
  • If pattern is not entered, will match any object that is a within a function call.
• Create useConfigurationIf.declarationName: { pattern?: string, scope?: "shallow" | "deep"}
  • Should resolve case 1 and 2.
  • If scope is not entered, take shallow by default.
  • I don't really think there is a use case with a non-existing pattern.

This should hopefully be able to cover all use cases.