`no-unreadable-object-destructuring` - configurable max depth levels

[risantos]

Description

Having rule config options on no-unreadable-object-destructuring to allow a configurable limit of depth other than the default 2.

In our specific case, some CJS projects would benefit from having 3 or 4 levels, without necessarily lose readability as we have the code style improving how readable they are using multiple lines while avoiding assigning to intermediary variables just to get the extra level of depth.

This is often seen in our codebase on tests where specific configs from node-config , or modules loaded from barrel files.

Examples

Current

If using 4 levels of depth.

// ❌
const {
  foobar: {
    settings: {
      foocycle: { duration: foobarCycleDuration }
    }
  },
  foobiz: { settings: foobizSettings },
  fooqux: { settings: fooquxSettings }
} = config.get('fooConfig');


// ✅
const {
  foobar: { settings: fooBarSettings },
  foobiz: { settings: foobizSettings },
  fooqux: { settings: fooquxSettings }
} = config.get('fooConfig');

const {
  fooCycle: { duration: foobarCycleDuration }
} = foobarSettings;

Proposed

If configurable to 3 levels, we could use the following:

// ✅
const {
  foobar: { settings: { foocycle: foobarCycleSettings } },
  foobiz: { settings: foobizSettings },
  fooqux: { settings: fooquxSettings }
} = config.get('fooConfig');

And have it adjusted to using foobarCycleSettings.duration. Or on 4 levels without adjustment, using the 1st failing example.

Additional Info

I'd likely leave the default 2 on most files and apply the setting for additional levels on specific file patterns as part of separate config objects.

This could be a maxDepthLevels option or equivalent. Usage:

• Default, no options

  'unicorn/no-unreadable-object-destructuring': 'error',

• Configured limit:

   'unicorn/no-unreadable-object-destructuring': ['error' { maxDepthLevels: 3 }],

[sindresorhus]

Thanks for the detailed write-up, but I’m going to decline this.

This rule is not a depth metric, it’s a set of judgmnts about destructuring shapes that are hard to read, and the two-level limit is one of them. Compare max-nested-calls or try-complexity, where a number is the entire point of the rule and therefore has to be configurable. Here, a maximumDepth option would turn off exactly the check the rule exists to enforce.

Your own example is the argument for keeping it. The four-level version is genuinely hard to scan, and the split version reads better. The cost is one intermediate variable, and having to name it is usually a feature.

The fair objection is that disabling the rule also loses the computed-key, nested-array, and property-assignment checks. But if this is really limited to a handful of config.get() calls in tests, an inline // eslint-disable-next-line unicorn/no-unreadable-object-destructuring at those sites is the right granularity, and it keeps everything else enforced.