Rule Change: no-empty-pattern allow parameters

[Faithfinder]

What rule do you want to change?

no-empty-pattern

What change to do you want to make?

Generate fewer warnings

How do you think the change should be implemented?

A new option

Example code

const handler = ({}, {}, usedParam) => {
  // use used param
}

What does the rule currently do for this code?

Warns

What will the rule do after it's changed?

I think this is a valid pattern as opposed to having _something naming scheme. I would love an option to allow this.

Participation

• I am willing to submit a pull request to implement this change.

Additional comments

No response

[Rec0iL99]

Hi @Faithfinder, thanks for the issue. This looks like a duplicate of #13315. The original issue could not get enough support from the team and hence was closed.

We currently aren't adding any new options or changes to the stylistic rules due to policy changes. You can always clone the existing rule and create a custom rule to fit your needs.

I'm not closing this for now since I'm not sure if this fits the description of a stylistic rule. Leaving it open for someone from the core team to look at.

[Faithfinder]

Ah! Sorry I didn't do a good enough search. I don't think it's entirely stylistic though. I'll await the verdict then

[mdjermanovic]

This rule is of type: "problem", so it is not considered stylistic.

I support this proposal 👍 though I'm not sure how common this pattern is as it doesn't work in case the argument can be nullish. Curious what other team members think about the proposal.

[snitin315]

This proposal makes sense to me 👍🏻. Any suggestions for the option's name?

[Faithfinder]

allowInParameters seems obvious?

[mdjermanovic]

Perhaps something like allowObjectPatternsAsParameters?

I think the option should work like this:

({}) => {}; // ok

({} = {}) => {}; // also ok

({ foo: {} }) => {}; // not ok

([]) => {}; // not ok

"in" parameters might suggest that empty patterns anywhere inside parameters would be allowed, e.g., ({ foo: {} }) => {}.

"Object" because it only allows empty object patterns, not array patterns.

[snitin315]

👍🏻 for allowObjectPatternsAsParameters . Marking this as accepted.

[Faithfinder]

I don't see why arrays shouldn't be allowed. Might be a natural choice in Typescript land, where the fact that it's an array is apparent

[Tanujkanti4441]

Perhaps something like allowObjectPatternsAsParameters?

I think the option should work like this:

({}) => {}; // ok

({} = {}) => {}; // also ok

({ foo: {} }) => {}; // not ok

([]) => {}; // not ok

@mdjermanovic, as per above comment ({ foo: {} }) => {} // not ok will give an error when allowObjectPatternsAsParameters option will be true, even if it is there as a function parameter.

"in" parameters might suggest that empty patterns anywhere inside parameters would be allowed, e.g., ({ foo: {} }) => {}.

Here you said ({ foo: {} }) => {} whould be allowed inside anywhere in parameters
Would you please clear this part more.

And is this new option only should allow the 'ObjectPatterns' in Arrow function and not for the function declaration?

[mdjermanovic]

as per above comment ({ foo: {} }) => {} // not ok will give an error when allowObjectPatternsAsParameters option will be true, even if it is there as a function parameter.

Yes, this should be an error. The empty pattern appears in parameters but it isn't in a parameter position so it doesn't make sense for the purpose of this option.

"in" parameters might suggest that empty patterns anywhere inside parameters would be allowed, e.g., ({ foo: {} }) => {}.

Here you said ({ foo: {} }) => {} whould be allowed inside anywhere in parameters Would you please clear this part more.

It should be allowed only at the first level, as the purpose is to skip positions in parameter lists.

And is this new option only should allow the 'ObjectPatterns' in Arrow function and not for the function declaration?

It should allow empty object pattern parameters in ArrowFunctionExpression, FunctionDeclaration and FunctionExpression nodes.