💅 useNamingConvention: The rule should ignore variables that are destructured out of objects

[vladkrasn]

Rule name

useNamingConvention

Playground link

https://biomejs.dev/playground/?lintRules=all&code=YwBvAG4AcwB0ACAAYQAgAD0AIAB7AAoAIAAgAFcAcgBvAG4AZwBDAEEAUwBFAFMAVABSAEkAQwBUADoAIAAxACwACgAgACAAQQBMAFMATwBXAFIATwBOAEcAOgAgADEACgB9AAoACgBmAHUAbgBjAHQAaQBvAG4AIABmAHUAbgBjACAAKABhACkAIAB7AAoAYwBvAG4AcwB0ACAAewAgAFcAcgBvAG4AZwBDAEEAUwBFAFMAVABSAEkAQwBUACwAIABBAEwAUwBPAFcAUgBPAE4ARwAgAH0AIAA9ACAAYQAKAGMAbwBuAHMAdAAgAG8AbgBlACAAPQAgAEEATABTAE8AVwBSAE8ATgBHACAAKwAgADEACgBvAG4AZQAgACsAIABXAHIAbwBuAGcAQwBBAFMARQBTAFQAUgBJAEMAVAAgACsAIABBAEwAUwBPAFcAUgBPAE4ARwAKAH0ACgA%3D

Expected result

Variables that are produced by destructured objects are not necessarily declared by a Biome user, they may come from a third party library. Maybe Biome should ignore them?

Code of Conduct

• I agree to follow Biome's Code of Conduct

[Sec-ant]

Instead of ignoring them, I think the expected behavior of this rule in this case should be suggesting renaming those destructured variables to comply with the naming convention.

[Conaclos]

I am hesitating between completely ignoring this kind of names or applying the suggestion of @Sec-ant.
The advantage of ignoring these names is to keep a low cognitive load by using the same name.

Note: we already ignore shorthand imports such as import { I_mport } from "mod".
We should certainly choose an identical strategy for this kind of code.

[ematipico]

Ther's also the fact that there's a pattern to remove properties from an object, like this:

const { SOMETHING, FOO, ...rest } = bar;

doSomething(rest);

This means that the user would be forced to write the code like this:

const { SOMETHING: something, FOO: foo, ...rest } = bar;

doSomething(rest);

I think this is very user-hostile and doesn't provide good value to the rule.