To be clear, this is what you want to happen, right?:

type HasMethod = { method(): void };
// actual
function f({ method }: HasMethod) {
}
// expected
function f({ method }: HasMethod) {
             ^^^^^^
}

Yes, that destructured assignment should trigger the rule the same way as if it were destructured in the body.

Awesome, thanks for the report! Seems like a bug to me as well.

Looking at past work it looks like this was probably just a simple oversight when the code was added that handles other cases of destructuring (#2228). Might be as simple as adding ObjectPattern to the rule.

I understand that it can be seen as a bug fix, but this is probably going to break many consumers who use the rule. For example, in my project, this is now flagged:

import { expect, test } from '@playwright/experimental-ct-react';

import SomeComponent from './SomeComponent';

test('some component', async ({ mount }) => {
  const result = await mount(<SomeComponent />);
  // ...
});

Note that Playwright makes it mandatory to use destructuring here so the only escape hatch is to disable the rule in tests.

It also affects React components with props defined like this:

interface TestProps {
  renderSomething(): string;
}

export function Test(props: TestProps) {
  const { renderSomething } = props;
  return <div>{renderSomething()}</div>
}

In that second case, I could rewrite my interface to fix it:

interface TestProps {
  renderSomething: () => string;
}

Note that Playwright makes it mandatory to use destructuring

Do you have a link for that?

In that second case, I could rewrite my interface to fix it:

Indeed, that would be a more correct way to write that type. +1 that this is a bug fix. The (): ... method declaration was incorrect to begin with.

Note that Playwright makes it mandatory to use destructuring

Do you have a link for that?

I can't find a direct mention in the documentation, but this is part of the test fixtures feature.

This is where they check for it.

I'm with @JoshuaKGoldberg - the change is a correct bug fix. So this issue is correctly closed as completed.

@targos Thanks for bringing this pain point up, though! Would you kindly spin off a new issue to continue the conversation? I think it merits discussion, so I wouldn't want this conversation to get buried by virtue of occurring in a closed issue.